Method and Apparatus for Improved Customer Direct On-Line Reservation of Rental Vehicles

ABSTRACT

Disclosed herein is a reservation booking website wherein customers who plan to travel via general aviation (GA) are provided with a GA reservation creation path that is responsive to their GA travel needs.

CROSS-REFERENCE AND PRIORITY CLAIM TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/361,239, filed Jan. 30, 2012, entitled “Method and Apparatus forImproved Customer Direct On-Line Reservation of Rental Vehicles”, nowU.S. Pat. No. 8,396,728, which is a continuation of U.S. patentapplication Ser. No. 11/039,203, filed Jan. 20, 2005, entitled “Methodand Apparatus for Improved Customer Direct On-Line Reservation of RentalVehicles”, now U.S. Pat. No. 8,108,231, which is a continuation-in-partof pending U.S. patent application Ser. No. 10/505,685, filed Aug. 25,2004, entitled “Method and Apparatus for Customer Direct On-LineReservation of Rental Vehicles Including Deep-Linking”, which is anational phase of PCT/US03/18553, filed Jun. 13, 2003, entitled “Methodand Apparatus for Customer Direct On-Line Reservation of Rental VehiclesIncluding Deep-Linking”, which is a continuation-in-part of pending U.S.patent application Ser. No. 10/172,481, filed Jun. 14, 2002, entitled“Method and Apparatus for Customer Direct On-Line Reservation of RentalVehicles”, the entire disclosures of all of which are incorporatedherein by reference.

FIELD OF THE INVENTION

The present invention relates to the automated processing and booking ofreservation transactions conducted over a computer network between acustomer and a reservation booking entity. In particular, the presentinvention relates to the on-line reservation of rental vehicles. Evenmore particularly, the present invention relates to the reservation ofrental vehicles over the internet through a consumer accessing adedicated web site.

BACKGROUND OF THE INVENTION

In the past decade, the use of the Internet in connection withcommercial activities (so-called “e-commerce”) has exploded intovirtually all areas of the business world. Among the businessesutilizing the Internet for e-commerce purposes have been car rentalbusinesses.

One of the ways that the car rental industry has utilized the power ofthe Internet is through on-line reservation booking. In addition to themany travel web sites, another way for a consumer to book a reservationover the Internet using an Internet-connected computer is to interactwith a server maintained by the entity that books the reservation. Tosuccessfully complete a reservation transaction, the customer mustgenerally provide the server with 3 or 4 basic types of information: (1)temporal information—when and for how long the car rental is needed(typically entered as pick up and return dates), (2) locationinformation—from which branch of the rental car company the rental caris desired to be obtained, (3) vehicle information —what type of vehicleis needed, and optionally (4) customer information—the customer's ageand/or name.

With these informational needs in mind, various websites dedicated toon-line booking of car rental reservations have been developed. Suchon-line reservation websites guide the customer through the reservationprocess so that the customer provides the server with the informationnecessary to complete a reservation transaction. Thereafter, the servercan create the reservation and post it to the rental car company'sdatabase. However, the current on-line reservation websites are notparticularly adept at guiding customers through the reservation processin a manner that provides both a high degree of user-friendliness andflexibility. Because of the rigid navigational structure of currenton-line reservation websites, it is believed that on-line reservationprocessing has not taken full advantage of the flexibility desired byconsumers and which will allow this marketing channel to reach its fullpotential.

FIGS. 1( a)-(d) illustrate an example of a conventional on-linereservation booking process. The customer accesses a page having a formthat includes a plurality of fields in which he/she can enter data. Somefields are required for the reservation to be booked, some are not(required fields are denoted by the *). If the customer submits data forless than all of the required fields, the form is returned to thecustomer with an indication that he/she must fill out all requiredfields to successfully submit a reservation. In the example of FIG. 1(a), it can be seen that the customer has entered “St. Louis Airport” inthe required location field, but has left all other fields blank. Whenthis form is submitted, the form of FIG. 1( b) would typically bereturned. Error indicators would typically be placed adjacent to theblank required fields, and an error message instructs the customer tofill all required fields. If the form of FIG. 1( c) represents theresult of the customer's next attempt to submit a reservation, it can beseen that the customer has now failed to include his/her age in theform. The confirmation form of FIG. 1( d) will typically only beprovided to the customer after an age is entered in the age field. Theconfirmation page of FIG. 1( d) is typically only presented to thecustomer after the customer has submitted all required fields and theserver has determined that a reservation is possible given the datasubmitted in the required fields (i.e., that a luxury sedan is availablefor rental at the St. Louis Airport branch from Aug. 1, 2002 throughAug. 3, 2002 to a 35-year old person).

Because of the different types of data needed to book a reservation (asexemplified by the required fields in the forms of FIGS. 1( a)-(c)), theon-line rental vehicle reservation process can be thought of as amulti-stage process, wherein each stage corresponds to receipt of aparticular type of necessary reservation information from the customer.That is, one stage relates to obtaining temporal information from thecustomer, another stage relates to obtaining location information fromthe customer, another stage relates to obtaining vehicle informationfrom the customer, and yet another stage relates to obtaining personalinformation from the customer.

Many current on-line rental vehicle reservation websites guide customersthrough these stages one stage at a time. That is to say, the customeris first presented with a page requesting that temporal information forthe reservation be provided. After the customer transmits the requestedtemporal data to the server, the server responds by presenting thecustomer with a page requesting that location information for thereservation be provided. After the customer transmits the requestedlocation data to the server, the server responds by presenting thecustomer with a page requesting that vehicle information be provided,and so on until the server receives all types of necessary data. Onceall types of necessary data are received, the server typically presentsthe customer with a verify page that summarizes the entered data. If thecustomer wishes to change any of the entries, that customer is typicallydropped back to the stage where revision is desired. In simplisticsystems, the customer must typically thereafter re-supply the serverwith the information for any stages downstream from the revised stage.In more advanced systems, the customer typically can be returned to theverify page after entering the revision data. FIG. 2 illustrates such aconventional linear process (the dashed line indicating the improvedrevision process).

Such conventional techniques suffer from a shortcoming in that acustomer who realizes that an error was made in entering stage 1 data(for example, entering the wrong starting date for the rental) but doesnot realize the mistake until stage 2, must typically process throughall the other stages before getting the opportunity to correct themistake. Because of this inconvenience, customer frustration may occurwhich could lead to the customer leaving the site without completing thereservation. Also, such conventional reservation techniques typicallyrequire the customer to complete reservation stages in a fixed orderdefined by the reservation booking entity and not the customer. Thus,customers typically do not have the freedom to complete stages in theorder they may desire. Another reservation booking process known in theart as of the filing date hereof is shown in FIG. 3. Rather than forcingthe customer to first complete a particular stage before proceeding to anext stage, the customer is allowed to first complete any of a pluralityof stages (but not the vehicle stage—which requires prior completion ofboth the time stage and location stage), and then proceed through eachindividual remaining stage in a single-step fashion. While such areservation system gives the customer the partial freedom to select theorder in which stages are completed, it still requires the customer tocomplete the reservation process sequentially using a fixed number ofminimum data exchanges. That is to say, for each stage, the customermust access the page associated with that stage before proceeding to apage associated with the next stage. This shortcoming unnecessarilydraws out the reservation process, thereby adding to customerfrustration and possible loss of a reservation.

Another feature of a known on-line reservation system is a summarysection that is provided on the left hand side of each page associatedwith a stage (the right hand side of each page is dedicated to promptingthe customer to enter the data for the stage associated therewith). Thesummary section lists the stage data entered by the customer. As thecustomer completes stages, the summary section is updated with the newdata entries. However, the competitor's summary section is a read-onlysummary. It is not interactive to allow the customer to directly selecta data entry he or she may wish to revise. If the customer, uponreviewing the summary section, decides that a stage needs to bere-visited to revise the data corresponding thereto, the customer mustcorrelate which stage is associated with the data needing revision andthen identify a tab or other pointer on the right hand side of the pageand select it to re-visit the stage associated with the data needingrevision. FIG. 4 illustrates this aspect of the known reservationsystem. The potential customer confusion that may be created ascustomers navigate through such an on-line reservation system is thoughtto increase customer dissatisfaction with the web site.

Log file research and usability tests have shown that customers willabandon websites as a function of the website's user-unfriendliness andinconvenience. As such, to maximize the potential of their e-commerceinvestment, it is highly important that reservation booking entitiesprovide an on-line reservation system that not only smoothly guides thecustomer from start to finish but also allows the customer someflexibility in navigating the site at their own desired pace with aminimum of inconvenience. This is especially the case due to theinherent uncertainty of speed and connectivity of the Internet. In otherwords, requiring potential customers to access increased numbers ofmenus or displays increases the amount of time required to successfullycomplete a reservation. These studies have shown that user drop outincreases as a function of time, so designing a web site which perhapsis easily implementable in HTML or other programming code may well leadto a rigid, single path architecture that is not optimized for userfriendliness, minimal data entry, and minimal display access steps.

SUMMARY OF THE INVENTION

Toward this end, the inventors herein have developed an on-linereservation transaction system wherein the customer can complete thestages of the reservation transaction via a customer-determined path,and not according to a strictly defined, straight-line architecture.

According to one aspect of the parent invention, disclosed herein is amethod of processing a reservation transaction between a customer andreservation-booking entity via a computer network connecting a customercomputer with an automated reservation transaction processor, thereservation transaction requiring submission of at least three differenttypes of reservation data from the customer for successful completionthereof, each reservation data type having one of a plurality ofdifferent values, wherein each reservation data type value is dependentupon other reservation data type values, the method comprising: (a)displaying a page on the customer computer, the page including (1) arequest that the customer submit values for at least two of thedifferent data types, and (2) for each requested data value, a datasubmitter through which the customer can submit a data value to theautomated reservation transaction processor; (b) receiving data at theautomated reservation transaction processor from the customer computerthat corresponds to a submission of a data value for at least one of thedata types; (c) determining from the received data at least one datatype, if any, that remains unsubmitted; (d) if any unsubmitted data typeis determined to remain, determining, on the basis of theinterdependence of the different data values for the differentreservation data types, a list of remaining acceptable values for the atleast one unsubmitted reservation data type; (e) displaying another pageon the customer computer, the another page including (1) said at leastone determined list of acceptable data submission values, and (2) foreach said determined list, a data submitter for submitting at least oneof said acceptable values to the automated reservation transactionprocessor; and (f) repeating steps (b) through (e) as necessary untilall required data types are successfully submitted to the automatedreservation transaction processor, thereby completing the reservation.

The reservation transaction is preferably a rental vehicle rentalreservation, wherein the types of necessary data comprise temporalinformation, location information, and vehicle information. Additionaltypes of necessary data types may include customer age information andother customer personal information (such as name, phone number,insurance carrier or preference, etc.).

The data values for the reservation data types are said to be dependentupon each other because it is not necessarily the case that all possiblecombinations of the different values for each reservation data type willbe acceptable to complete a reservation. That is, in a given reservationtransaction, a particular data value for a particular data type mayrestrict the range of acceptable values for other data types. Forexample, the value of “luxury” for vehicle type may display a range oflocation values but restrict the range of acceptable location valuesfrom locations 1-10 to only locations 3 or 4; or the value of Jul.10-14, 2002 for starting/end time and the value of Location X forlocation may restrict the range of acceptable values for vehicle typesfrom all vehicle types to only “economy” and “compact”. Thus, the rangeof acceptable values for each reservation data type are preferablydependent upon availability given any previous data value entries forother reservation data types. At the same time, the user may choose tochange one of the limiting data values to thereby change the resultingrange of acceptable data values for other data types. Because the parentinvention preferably narrows the customer's data submission options to alist of acceptable values for an unsubmitted data type on the basis ofwhat values are acceptable for successful completion of a reservationgiven the previous data value submissions for the other data type,customers are guided toward making choices that correspond to actualavailability of vehicles, times, locations, etc. which therebyeliminates the customer receiving an “unavailable” message requiring himto re-select for these values. This maximizes the likelihood of thepotential consumer staying on the web site and successfully booking areservation with minimal potential for dissatisfaction.

According to another aspect of the parent invention, herein is discloseda method of processing a reservation transaction between a customer anda reservation-booking entity via a computer network connecting acustomer computer with an automated reservation transaction processor,the reservation transaction requiring a plurality of customer-enteredpieces of information that are necessary for successful completionthereof, the method comprising displaying a page on the customer'scomputer, the page being configured with (1) at least one field for thecustomer to submit a piece of necessary information, and (2) a summarythat includes (a) a list comprised of any pieces of said necessaryinformation previously submitted by the customer and (b) at least oneselectable edit link for requesting a data submitter for entering atleast one revised data value for at least one piece of said necessaryinformation.

The use of such an interactive summary on the interactive web pages ofthe parent invention allows customers to quickly and easily enter anychanges to the previously-submitted data.

According to yet another aspect of the parent invention, deep-linking isprovided for customers seeking to book a reservation from a promotionallink or from a corporate account. The promotion corresponding to apromotional link that may be selected by a customer may have one or morepromotion conditions, each promotion condition corresponding to aparticular data value or range of data values that the customer mustchoose for a particular reservation data type. For example, a promotionoffering a reduced rate may only be valid for a single vehicle type ormay only be valid for a limited time. Similarly, a corporate account mayinclude limiting parameters analogous to promotion conditions. With theparent invention, when a customer selects a promotional link or aparticular corporate account, that customer is deep-linked into thereservation booking process such that the data values for any data typethat correspond to a promotion condition (or a corporate accountparameter) are identified in the accompanying text. Also, anyreservation data types corresponding to promotional conditions (orcorporate account parameters) have their data values set equal to thoseconditions/parameters. Should the customer submit a data value thatviolates a promotion condition (or corporate account parameter), thenthe parent invention notifies the customer of this situation andpresents him/her with an option to revise the data value causing theviolation of a promotion condition/corporate account parameter.Instructional text may also be found on subsequent pages. Alternately,the customer may elect to continue the process and not take advantage ofthe promotion or move off the corporate account.

By deep-linking into the website those customers who are seeking to takeadvantage of an offered promotion (or an available corporate account),the parent invention avoids inconvenience to the customer that wouldresult from requiring the customer to first learn what data values needto be entered to satisfy the conditions of the promotion and thenentering those values. Those steps are bypassed by deep-linking thecustomer to a point in the reservation booking process where data valuesrelating to promotional conditions are automatically set to theconditional values. Also, by notifying the customer when a submitteddata value for a reservation data type violates a promotion condition(or corporate account parameter) and by giving the customer the optionto accordingly revise that data value, the parent invention avoids thecustomer dissatisfaction that may arise from the customer losing out ona desired advantage because of an unintentional violation of a promotioncondition or corporate account parameter.

As part of this deep-linking concept, repeat users such as regularcustomers and on-going business partners of the reservation bookingentity can be provided with a URL that is operative to deep-link acomputer user into the reservation server site in accordance with acorporate account maintained with the reservation booking entity by therepeat user. This URL can be placed on the repeat user's computer system(such as an Intranet site) as a hyperlink that can be selected bycustomers who want to book a reservation from that computer system,wherein the reservation takes advantage of any deals or rates that areavailable through the repeat user's account.

Further, it is worth noting that travel agents (or travel agentorganizations) can act as a business partner who uses a corporateaccount. Further still, travel agents can be provided with identifiersthat allow the system to track and assess commissions to the travelagents for booked reservations as may be appropriate.

Further still, according to another aspect, a user interface can be usedto define the parameters of a corporate account, customer account, orpromotional offer. Such an interface provides fast, flexible controlover account parameters that are tailored to the wishes of, for example,a business partner for whom a corporate account is created.

According to yet another aspect of the parent invention, the parentinvention can be implemented to use web services for data exchangesbetween the customer computer and the reservation booking website. Withweb services, XML messages using standard formatting are passed betweenthe customer computer and reservation booking website. XML messagingprovides for increased speed and ease of connection between the customercomputer and the reservation booking website, and further offersimproved reuseability and a substantial decrease in the configurationchanges needed for the customer computer-to-reservation booking websitecommunications.

The parent invention further provides an efficient use of a user's timeand network connectivity, by minimizing the required amount ofinteractivity, and movement of data/displays from the reservationbooking website and the customer's computer. As is known in the art,delays are commonly experienced on the Internet due to the requiredtransmission of large amounts of data to create displays so thatminimizing the number of displays must necessarily speed up the processof a user making an Internet reservation.

Still another aspect of the parent invention is the design feature thatcreates a summary section with hyperlinks for a user to convenientlyclick and move to a display to change the corresponding data needed tocomplete the reservation. This summary is further advantaged byoccupying less than all of the display screen. This feature of theinvention focuses the user on the single most important task at hand,i.e. that of completing the reservation in a manner acceptable to theuser, with the correct information entered, and with perhaps the mostuser-friendly and intuitive method for correcting/changing anyinformation needed for completing the reservation.

The invention thus adapts the website architecture to the user's needs,and points every user action towards completing the reservation tothereby maximize the “completion” rate of reservations achieved comparedto the number of users accessing the website.

According to yet another aspect of the invention, disclosed herein is animprovement to the personalized customer profiles/accounts of the parentinvention, wherein the functionality of managing customerprofiles/accounts is expanded upon to provide customers with greatercontrol over the profile data stored in their associated personalizedaccounts/profiles, particularly in connection with the “favorite” or“preferred” branch locations for rental vehicle reservations that arestored in the customer profiles/accounts and which may be used to“pre-populate” one or more data entries.

According to yet another aspect of the present invention, the preferredreservation booking website has been expanded to meet the travel needsand particularly the rental vehicle needs of general aviation (GA)travelers, i.e. those travelers who fly on non-military, civil aviationother than scheduled airline flights. As part of this aspect of thepresent invention, a GA rental vehicle reservation creation path ispreferably provided within the reservation booking website thatinteracts with customers traveling via GA in a manner that is responsiveto their GA travel needs. In particular, in a preferred aspect of thisfeature of the invention, the reservation booking website facilitatesthe selection of a branch location for a customer's rental vehiclereservation based at least in part upon a Fixed Base Operator (FBO)service to be used by the customer as part of his/her GA travel plans.

According to yet another aspect of the present invention, customers areprovided with a streamlined ability to log into their customerprofiles/accounts. As part of this aspect of the present invention,fields for customer entry of a password for a customer profile/account(and optionally a field for customer entry of a user name for a customerprofile/account) are provided on several of the displayed web pages(e.g., a choose vehicle page, a renter information page, a chooselocation page etc.), or more preferably, on all of the web pages thatare displayed to the customer when the customer has not yet logged intohis/her profile/account. This feature allows a user to quickly navigateto a profile/account from other pages than just a home page (or startpage or splash page), for example. A home/start/splash page can best bedescribed as the initial main user interface through which the userprovides reservation data to the reservation booking website. Oftentimes, the home/start/splash page will allow the user to enter data fora plurality of reservation data types (e.g., temporal, location, andvehicle data).

These and other features and advantages of the present invention will bein part apparent and in part pointed out in the following descriptionand referenced figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1( a)-(d) illustrate a prior art technique by which a reservationbooking website obtains reservation data from a customer;

FIG. 2 illustrates another prior art technique by which a reservationbooking website obtains reservation data from a customer;

FIG. 3 illustrates yet another prior art technique by which areservation booking website obtains reservation data from a customer;

FIG. 4 illustrates a known technique for providing a customer with asummary of existing reservation data as the customer proceeds throughthe various stages of the reservation booking process;

FIG. 5 illustrates an overview of the reservation data gatheringtechnique of the parent invention, wherein 3 types of reservation dataare needed;

FIG. 6 illustrates a preferred architectural overview for the parentinvention;

FIG. 7 illustrates the preferred automated reservation transactionprocessor in more detail;

FIG. 8 illustrates a preferred technique for how the parent inventionprocesses data received from the customer;

FIGS. 9-12 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from thehome page;

FIG. 13 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toobtain general locational information from the customer;

FIGS. 14-15 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to obtain a branch selection from the customer;

FIGS. 16-17 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to obtain a vehicle selection from the customer;

FIGS. 18-19 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to provide the customer with detailed information about aselected vehicle;

FIGS. 20-23 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to provide the customer with detailed information about aselected branch;

FIG. 24 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toobtain pertinent personal information about the customer;

FIGS. 25-26 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to allow the customer to review and verify the reservation dataprior to booking;

FIG. 27 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a reservationconfirmation page;

FIGS. 28-29 illustrate various preferred navigational paths for thereservation booking process of the parent invention starting from pagesdesigned to allow the customer to change the reservation time;

FIG. 30 illustrates a preferred navigational path for the reservationbooking process of the parent invention starting from a page designed toallow the customer to change the age data;

FIG. 31 illustrates an overview of how the parent invention allows acustomer to deep-link into the reservation booking process upon theselection of a promotional link;

FIG. 32 illustrates the promotional deep-linking aspect of the parentinvention;

FIG. 33 illustrates how the parent invention allows a customer who isfollowing a promotional path to make informed decisions when enteringdata to avoid violating the conditions of the promotion;

FIG. 34 illustrates an overview of how the parent invention allows acustomer to deep-link into the reservation booking process with use of acorporate account;

FIG. 35 illustrates the corporate account deep-linking aspect of theparent invention;

FIG. 36 illustrates how the parent invention allows a customer who isfollowing a corporate account path to make informed decisions whenentering data to avoid violating the parameters of the corporateaccount's profile;

FIG. 37 is a screenshot of a preferred home page (H) for the parentinvention;

FIGS. 38-41 are screenshots of preferred “choose location” pages(CL1-CL4) for the parent invention;

FIGS. 42-43 are screenshots of preferred “choose vehicle” pages(CV1-CV2) for the parent invention;

FIGS. 44-45 are screenshots of preferred “vehicle details” pages(VD1-VD2) for the parent invention;

FIGS. 46-49 are screenshots of preferred “branch details” pages(BD1-BD4) for the parent invention;

FIGS. 50( a)-50(b) are screenshots of a preferred “renter information”page (RI) for the parent invention;

FIGS. 51-52 are screenshots of preferred “verify” pages (V1-V2) for theparent invention;

FIG. 53 is a screenshot of a preferred “confirmation” page (Conf) forthe parent invention;

FIGS. 54-55 are screenshots of preferred “change time” pages (ChT1-ChT2)for the parent invention;

FIG. 56 is a screenshot of a preferred “change age” page (ChA) for theparent invention;

FIG. 57 is a screenshot of a preferred “stripped down home page” page(SH) for the parent invention

FIG. 58 is a screenshot of a preferred “after hours” page (AH) for theparent invention;

FIGS. 59-61 are screenshots of preferred “apology” pages (APOL1-APOL5)for the parent invention;

FIG. 62 is a screenshot of a preferred “cancel reservation” page(Cancel) for the parent invention;

FIG. 63( a) is a screenshot of a preferred “promotional parametersnotice” page (Notice) for the parent invention;

FIG. 63( b) is a screenshot of a preferred “corporate account parametersnotice” page (Notice) for the parent invention;

FIG. 64 is a screenshot of a choose location page, wherein the list ofavailable branch locations has been restricted to airport branchlocations;

FIG. 65 is a screenshot of a branch location search page;

FIG. 66 is a screenshot of a list of branch locations returned after auser has entered search criteria on the page of FIG. 65;

FIG. 67 is a screenshot of a branch location details page that isdisplayed upon selection of a branch location from the page of FIG. 66;

FIG. 68 illustrates a preferred format for a “get rates” web servicerequest and response;

FIGS. 69( a) and (b) illustrate a preferred format for a “createreservation” web service request and response;

FIG. 70 illustrates a preferred format for a “get reservation” webservice request and response;

FIGS. 71( a) and (b) illustrate a preferred format for a “modifyreservation” web service request and response;

FIG. 72 illustrates a preferred format for a “cancel reservation” webservice request and response;

FIG. 73 illustrates a preferred GUI for defining the parameters of anaccount or promotional offer;

FIG. 74 is a flowchart depicting GA/FBO functionality in the context ofbooking a reservation through a preferred GA path within the reservationbooking website;

FIGS. 75( a)-(d) illustrate preferred pages that include a GA/FBO link;

FIG. 76 illustrates a preferred GA/FBO homepage;

FIG. 77 depicts a window for identifying the airport codes for allairports in the U.S., including GA airports;

FIG. 78 depicts a preferred “Choose FBO” page;

FIG. 79( a) depicts a preferred “Choose Vehicle” page within the GApath;

FIG. 79( b) depicts a preferred “Branch Details” page within the GApath;

FIGS. 80( a)-(f) depict various preferred pages that include a customerprofile log in section;

FIG. 81 depicts a preferred “Choose Location” page wherein the customerhas already logged into his/her customer profile;

FIG. 82 depicts an alternate customer profile log in section;

FIG. 83 illustrates a preferred navigational flow for managing acustomer profile;

FIG. 84 depicts a preferred page for customer entry of basic renterinformation for a customer profile;

FIG. 85 depicts a preferred “Main Profile” page for managing a customerprofile;

FIG. 86 depicts a preferred branch location search page for use inmanaging a customer profile;

FIG. 87 depicts a preferred “Choose Favorite Branch Location” page;

FIG. 88 depicts a preferred modify favorite location page;

FIG. 89 illustrates an alternate preferred navigational flow formanaging a customer profile;

FIG. 90 depicts a preferred homepage that includes a favorite branchlocation selection section;

FIG. 91 depicts a preferred flow for creating a customer profile fromreservation data provided by the customer when creating and booking areservation; and

FIG. 92 depicts a preferred “Main Profile” page for managing a customerprofile when creating a customer profile from reservation data providedby the customer when creating and booking a reservation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 5 illustrates the basic navigational structure for the reservationbooking website of the parent invention. In the example of FIG. 5, thedifferent types of data needed from the customer to successfully book arental car reservation are: (1) temporal data (T)—such as the startingand ending dates for the reservation, (2) location data (L)—such as anidentification of the particular branch of the rental car company fromwhich the customer seeks a car rental reservation, and (3) vehicle data(V)—such as the type of vehicle the customer wants to rent (economy,midsize, luxury, etc.). The customer can submit values for these datatypes to the reservation booking entity via a customer-determined numberof stages. Each box in FIG. 5 represents a page of the website, and thetext within each box represents the data types for which the pagerequests data values from the customer. Each arrow indicates asubmission of data by the customer, and the text adjacent each arrowrepresents the type(s) of data being submitted.

The customer, depending on his/her desires, can either submit all datavalues for all necessary data types to the reservation booking entityvia a single data exchange 104, two data exchanges 102, or insingle-step fashion via three data exchanges 100. Once the reservationbooking entity has received all necessary data from the customer, averify page is presented from which the customer can review his/her dataentries and thereafter book the reservation if all is accurate.

In the single data exchange 104 wherein the customer submits temporal,locational, and vehicle data at the same time, the reservation bookingentity must consult a database to determine whether a reservation havingthose data values is possible. If not, the customer will be guided toamend one or more of the reservation data entries.

In the two-step data exchange 102, the reservation booking entity canprocess the double submission (TL, TV, or LV) to determine how to moreaccurately guide the customer through the process. For example, if bothT and L are submitted at once, the reservation booking entity knows thatvehicle data is still needed, but because both T and L data have beensubmitted, it can refine the customer's options for selecting vehiclesto only those vehicles available at the selected time from the selectedlocation. This aspect of the invention is taken one step further in thethree-step data exchange 100. On each submission of data, thereservation booking entity processes the submitted data on the basis ofthe data values interdependent to refine the number of acceptable datavalue options for the remaining data types.

FIG. 6 illustrates a preferred architecture for the parent invention. Aplurality of customer computers 210 connected to a network 204 (such asthe Internet) and using web browsing software can access a reservationbooking website hosted by automated reservation transaction processor150. Automated reservation transaction processor 150 can be any computerthat is network connectable. Preferably, the processor 150 comprises anapplication server 200 (or application servers for redundancy purposes)a web server (or servers) 200, a customer/promotional database 208, anda business database 206. The application server 200 (1) interacts withthe customer computers via web server 202 (or web servers) to obtainreservation data therefrom, (2) interacts with business database 206 viaa connector interface such as Tuxedo, and (3) interacts with acustomer/promotional database 208 via a connector interface such asJDBC. Business database 206 stores all of the data pertaining to therental car company's branch locations, vehicle inventories, pricing,etc. Customer/promotional database 208 preferably stores the profiles ofany registered customers, the profiles of any corporate accounts, anddata relating to any rental promotions being offered by the company.

FIG. 7 illustrates the automated reservation transaction processor 150in greater detail. Application server 200 preferably runs WebLogic 6.1software 250 and interfaces with web server 202 (preferably an Apacheweb server 242) via a servlet 220 and a Java Server Page (JSP) 222,preferably using Struts architecture. The servlet communicates with apersonalization application programmer's interface (API) 228 to storeand retrieve customer profiles and a promotions API 230 to retrievepromotional data. The APIs 228 and 230 link with EJB connector logic 232which in turn links with JDBC connector logic 234. The JDBC connectorlogic 234 allows the application server 200 to communicate with databaseserver 208 (which is preferably an Oracle or Informix database 236). Theserver also communicates with the business database 206 via EJBconnector logic 224 and WebLogic Tuxedo connector 226. The businessdatabase server 206 is preferably an AS/400s implementing Tuxedoservices 240 and Tuxedo connector 238.

Servlet 220 performs the major decision-making tasks for the reservationbooking process of the parent invention. Servlet 220 interacts with thedatabases to gather necessary information for both (1) determining whichpage should be constructed by the JSP 222, and (2) the particular datathat should appear on the page. Upon reference to the navigationalcharts and screen shots of the succeeding figures, a programmer havingordinary skills can readily implement the programming needed toimplement the parent invention, particularly the servlet 220 and JSP222. Also, as one of ordinary skill in the art would readily recognize,any of a number of servers and software platforms can be used inconnection with the parent invention. As such, the parent invention isin no way limited by the configurations shown in FIGS. 6 and 7.

FIG. 8 is a flowchart illustrating how the application server 200processes data received from customers. At step 8.1, the applicationserver receives a data submission from a customer computer. Using FIG. 5as an example, this data may relate to T, L, or V. At step 8.2, theapplication server creates a reservation transaction for the customercomputer and stores the received data therein. Next at step 8.3, theapplication server processes the received data to determine whatinformation is still needed from the customer to complete a reservation,and what information the customer needs to make a meaningful decisionwhen deciding what to choose for the remaining data. To make suchdecisions, the servlet 220 interacts with the business database 206. Forexample, if servlet has received T and L data from the customer, theservlet determines that V data is still needed and queries databaseserver 206 for all vehicles available from the selected L at theselected T. Preferably, the servlet also queries the database foradditional information pertaining to the available vehicles, such as aprice and a general description (both of which can be included in thepage to be built and sent to the customer). At step 8.4, the servletthen interacts with JSP 222 to build a web page with necessaryinformation and hyperlinks that allow the customer to make a furtherdata submission that will at least partially satisfy at least oneremaining reservational data need. Thereafter, at step 8.5, the customercomputer accesses the built page and the process repeats itself asadditional data submissions are received from the customer computer.

In addition to using traditional data exchanges between the customercomputer and the website over the Internet, the parent invention mayalso be implemented with web services to use XML data exchangesaccording to the Simple Object Access Protocol (SOAP). FIGS. 68 through72 illustrate the XML formats for a preferred web servicesimplementation of the parent invention. Under this implementation,various business partners of the reservation booking entity are providedwith URLs for these services. Through these URLs, employees or personsauthorized by the business partner may book reservations via the websiteusing the web services shown in FIGS. 68-72 and described below. A listof the IP addresses of the business partners having authorization to useweb services is preferably maintained so that incoming service requestscan be checked on the basis of IP address to ensure that only the webservices business partners gain access to these services. However, itshould be understood that the parent invention can also be implementedwith limited access to web services beyond a limited group of businesspartners as well as be implemented with unrestricted access to the webservices.

It is preferred that the customer communicating with the reservationbooking website pass data to the web services via the Open TravelAlliance (OTA) 2002 XML standard using SOAP. Further, it is preferredthat the following web services be provided: a “Get Rates” service, a“Create Reservation” service, a “Get Reservation” service, a “ModifyReservation” service, and a “Cancel Reservation” service.

FIG. 68 illustrates the preferred formatting for the “Get Rates” servicerequest and response. The “Get Rates” service operates to provide thecustomer with pricing data regarding one or more particular vehiclerental transactions. The customer computer passes the data values (seecolumn 600) for various data variables of interest (see column 602) tothe reservation booking website in a tagged format as an XML document.For example, in FIG. 68, for the data variable tag PickUpDateTime, thecustomer has provided data indicating a rental vehicle pick-up date ofMay 19, 2003 at the time 1:00 pm, and for the data variable tagReturnDateTime, the customer has provided data indicating a rentalvehicle return data of Jun. 16, 2003 at the time 3 pm. The location codefrom which the customer intends to pick up the rental vehicle (the firstLocationCode variable) is identified as St. Louis Airport (airport codeSTL), and the location code at which the customer intends to return therental vehicle (the second LocationCode variable) is also identified asSt. Louis airport. While this example uses airport codes as the locationcode, it should be understood that the location code used by the parentinvention can be any identifier assigned to any branch location,including non-airport branch locations, or a geographic identifier for aparticular geographic region near where the reservation is desired.

Upon receipt by the website, the website parses the XML document toextract the pertinent data, and maps the data to Java objects that canhanded off to the reservation transaction processor for a determinationof the appropriate pricing rates for such a vehicle rental transaction.After this pricing rate information is determined, the website returnsthe data shown below the “values returned” notation of FIG. 68 to thecustomer computer as an XML document. The core information should matchthe corresponding data provided by the customer. Further, the websitewill return vehicle availability data as to status (available orunavailable) and size. The number data values for vehicle size relate tothe class of the rental vehicle, with the numbers 3, 4, 6, 7, 8, 10, 9,11, and 24 corresponding, respectively, to vehicle types economy,compact, intermediate, standard, full size, premium, luxury, minivan,and exotic (e.g., SUV).

Further, the website returns rental rate data values for amount (rate),currency code (e.g., US dollars, British pounds, etc.), a description ofthe rate type (hourly, weekly, surcharge, total charges), quantity (thenumber of vehicles), unit charge, total charge (the final cost), and anyapplicable mileage rules. Further, the website response includes datarelated to the customer's coverage.

The location information for the applicable pricing rate is set forth inthe format, name (branch name), address, postal code, country name,state/province, city name, phone use type, telephone number, andtelephone number area code/city code. Lastly, additional information isreturned by the website, such as any age rules that may apply (“age”)and, possibly notices about available shuttle services (“shtl”), noticesabout available after hours services (“afhr”), or miscellaneousinformation (“misc”). The text for such additional information is alsoidentified.

FIGS. 69( a) and (b) illustrate the format for the preferred “CreateReservation” service request and response. Customers preferably utilizethis service to create a rental vehicle reservation. Relative to the“Get Rates” service, the “Create Reservation” service includes, on thecustomer send side, various pieces of information about the prospectiverenter. However, as would be understood by those of ordinary skill inthe art, not all fields of data would be required to complete areservation transaction, although it is preferred that at least asurname is provided.

Upon receipt of the dat provided by the customer, the website seeks tocreate a reservation in accordance with the data provided. If areservation is not available under the user-provided conditions, anerror message will be returned. However, if possible, a success flag inthe website response is returned to the customer computer together withthe renter information data, reservation core data (including areservation confirmation number), vehicle information, rental rateinformation, priced coverage information, location information, andadditional information as set forth in FIGS. 69( a) and (b).

FIG. 70 illustrates the format for the preferred “Get Reservation”service request and response. This service operates to allow a customerto retrieve data about a pre-existing reservation. The retrievalcriteria, preferably include a confirmation number and renter name asshown, but as would be understood, either criteria could be used. Uponreceipt of this data as part of the “Get Reservation” service request,the website can query the reservation database using the confirmationnumber and/or renter name to obtain the pertinent reservation data. Theinformation described in FIG. 70 is thereafter returned to the customercomputer by the website as an XML document for display on the customer'scomputer.

The preferred “Modify Reservation” service of FIGS. 71( a) and (b) issimilar to the “Create Reservation” service except that the customercomputer provides a confirmation number to the website so that theappropriate reservation can be modified. Further, the returned datavalues include a flag for the “modify status” of “modified” or“unmodified”. It would generally be expected that a customer wouldutilize the “Modify Reservation” service after utilizing the “GetReservation” service. In using the “Modify Reservation” service, thecustomer will modify one or more fields in the reservation core data andrenter information data. Upon receipt of the customer-provided data asan XML message, the website parses the message and determines whether areservation in accordance with the modified data is possible. If not, anerror message is returned, if so, the return message of FIG. 71( b) issent to the customer computer.

FIG. 72 illustrates the preferred format for the “Cancel Reservation”service request and response. This service is similar to the “GetReservation” service from the perspective of the data provided by thecustomer, but is operative to cancel an existing reservation. Uponreceipt of a valid customer cancellation service request, the websitereturns an XML message as shown in FIG. 72( b) wherein the cancel statusis “cancelled” and the cancelled reservation confirmation number isidentified.

The navigational path for the reservation booking website of the parentinvention will now be described. FIG. 9 shows a navigational pathstarting from the home page wherein a zip code has been entered aspartial location information. FIG. 38 illustrates a preferred format forthe home page (H) of the parent invention.

With reference to FIG. 38, page H includes a plurality of fields inwhich the customer can enter reservation data. The four basic types ofreservation data are preferably location information (L), temporalinformation (T), vehicle information (V), customer age (A), andadditional customer information (RI). From the home page, the customercan preferably enter data for L, T, V, and A. Also, it should be notedthat the website can be designed to recognize returning visitors throughthe use of cookies or customer registration, which would eliminate theneed to repetitively gather A and RI information from repeat customers.

Preferably, a customer enters partial L data from the home page thatwill allow the processor 150 to determine a general area (such as ametropolitan area or state) from which the customer is interested inrenting a car. In locational field 302, the customer can enter either azip code, an airport code, or general search text. Business database 206preferably associates each branch location with a plurality of nearbyzip codes to enable zip code searching. Also, any branch locations thatare designated as airport branches (preferably branches near an airport)are associated with the 3 character airport code of the nearby airportto enable airport code searching. If general search text is entered, theservlet will query the business database 206 for all branch locationshaving the entered text anywhere in its address. However, it should beunderstood that other locational search methods may be readilyimplemented (including but not limited to methods such as a drop downmenu listing all of the rental car company's branches—which is not veryefficient for a large rental car company having thousands of branches, apop-up map with geographically-placed hyperlinks, cascaded searches bystate then city then branch, or the like). If a customer wishes thatonly branch locations associated with airports be returned but does notknow the airport code for the airport of interest, a box 326 is providedthat restricts the branches returned from a zip code or general textsearch to only airport branches that satisfy the zip code/text searchcriteria.

Full temporal information is preferably provided in fields 304, 306,308, and 310 which correspond to starting date, starting time, returndate, and return time respectively. It is preferred that default valuesbe used for the temporal information (such as the current date forstarting/end dates and noon for starting/end time) in the event that thecustomer does not enter T data from the home page. In the event errordata is received as a date, the customer will be linked to a “strippeddown” version of page H (SH, see FIG. 57) to re-enter valid temporaldata.

Vehicle information is preferably provided in field 314. A drop downmenu can list available vehicle types (including but not limited totypes such as compact, economy, mid-size, and luxury). Preferably thevehicle type defaults to “all vehicle types” in the event that thecustomer does not enter V data from the home page.

Customer age information is preferably provided in field 322. A dropdown menu can list possible age ranges (including but not limited tobelow 20, 21-24, and 25+). Preferably the age defaults to 25+ in theevent that the customer does not enter A data from the home page.

Upon entering data in any or all of the above-described fields, thecustomer can submit the data (including any default temporal or ageentries that may exist) to the processor 150 by selecting link 324. Thedata entry fields and the “search” link 324 make up a data submitterthrough which the customer can submit at least one data value. It shouldbe noted that the parent invention is not limited to a data submitter asshown in FIG. 37 but encompasses data submission techniques of allkinds, such as a data submitter that is a list of hyperlinks with eachhyperlink corresponding to a different acceptable data value, a datasubmitter that is a drop-down menu of selectable options and acorresponding “select” link, or the like.

Additional preferable features for the home page include (1) variouspromotional links 318 that correspond to any promotions that the rentalcar company is offering (each promotional link 318 being selectable toinitiate a reservation transaction according to the conditions of thepromotion), (2) an “enter corporate account” field 316 through which acustomer can access a corporate account and initiate a reservationtransaction according to the parameters of a profile associated with thecorporate account (preferably the corporate account is accessed byentering a password or the like in field 316), and (3) a “modify anexisting reservation” link 320 which allows a customer to access and/ormodify an existing reservation by entering a reservation confirmationnumber or some other suitable identifier when subsequently prompted. Oneor more message tiles 317 may also be provided on page H (or any pageother than SH). The message tile 317 includes either a link 318 to apromotion or a link to accessing a customer's corporate account.Preferably the message tile 317 is positioned on either end (left orright) of the page, preserving the center of the page for reservationdata interaction.

Returning to FIG. 9, when a customer has selected link 324 afterentering a zip code in field 302, the servlet accesses the businessdatabase to determine the state in which the zip code is located and thebranch(es) associated with that zip code. If the received age data(which may either be the default age data or customer-entered age data)is below the minimum age for renting a vehicle in the zip code's state(21 in most states, 18 in New York), then the servlet links the customerto page APOL3 (see FIG. 61). If not, the servlet queries the database206 to determine whether any returned branches are open at the startingdate and starting time received from the customer (which may be eitherdefault values or customer-entered values). If no such branches areopen, the servlet links the customer to either page CL1 (if a vehicletype has been selected, see FIG. 38( a)), or page CL2 (if no vehicletype has been selected, see FIG. 39). On the displayed CL page, theindicated status for each listed branch will be “closed”.

If open branches do exist, and only one such open branch exists, theservlet proceeds through steps 9.5-9.21. If the customer selected avehicle type from the home page, and the selected vehicle is bothavailable at the branch and available for the customer's age, theservlet links the customer to page BD2 (see FIG. 47) which allows thecustomer to learn more about both the single returned branch (address,etc.) and the vehicle selected (such as price, etc.). If the customerselected a vehicle type from the home page, and the selected vehicle isavailable at the branch but not available for the customer's age, theservlet links the customer to page APOL3 (see FIG. 62) which informs thecustomer of the vehicle's unavailability based on an age restriction. Ifthe customer selected a vehicle type from the home page, and theselected vehicle is not available at the branch but other cars areavailable at the branch, the servlet links the customer to page BD1 (seeFIG. 46) or BD4 (see FIG. 49) depending upon whether the branch isdesignated an airport branch. BD1 and BD4 let the customer know of theother vehicles that can be selected at the branch while also informingthe customer about the single returned branch. Because airport branchesoften have extended operating hours, after closing vehicle drop-offs,and shuttle services, airport branches are given special attention inthe parent invention (although this need not be the case). If thecustomer selected a vehicle type from the home page, and the selectedvehicle is not available at the branch, nor are any vehicles availableat the branch, the servlet links the customer to page APOL1 (see FIG.59) or APOL2 (see FIG. 60) depending upon whether the branch is anairport branch. APOL1 will provide the customer with a link outside thesummary section (to be described below) that allows the customer tochange branch locations. APOL2 preferably does not provide such a linkoutside the summary section. Both APOL1 and APOL2 inform the customerthat the branch has no vehicles available at the selected starting time.If the customer did not select a vehicle type from the home page, andthe selected vehicle is not available at the branch, nor are anyvehicles available at the branch, the servlet links the customer to pageAPOL1 (see FIG. 59). If the customer has not selected a vehicle typefrom the home page, and the selected vehicle is not available at thebranch but other cars are available at the branch, the servlet links thecustomer to page BD1 (see FIG. 46) or BD4 (see FIG. 49) depending uponwhether the branch is designated an airport branch, which lets thecustomer know of the other vehicles that can be selected at the branch.

If more than one open branch is returned from the database query at step9.4, the next action needed from the customer is a selection of one ofthe plurality of branch locations meeting the zip code search criterion(steps 9.22-9.24). Depending upon whether the customer entered a vehicletype, the servlet links the customer to either page CL1 (see FIG. 38) orCL2 (see FIG. 39) which list the locations available for selection basedon the submitted data.

FIG. 10 illustrates essentially the same process as FIG. 9 with theexception that the customer entered search text in field 302 rather thana zip code (which affects the “choose location” pages now denoted asbeing either CL3 and CL4, see FIGS. 40-41). Likewise, FIG. 11illustrates essentially the same process as FIGS. 9 and 10 with theexception that the customer has either entered an airport code in field302 or entered either a zip code or search text in field 302 afterchecking box 326. Because it is known that only airport branches arereturned from the database query, the process of FIG. 11 (unlike thoseof FIGS. 9 and 10) does not need any decision-making based on whether aparticular branch is flagged as an airport branch.

FIG. 12 illustrates a navigational flow from the home page where thecustomer enters any combination of age, vehicle, and/or time data—but nolocational data is entered in field 302. In such cases, the servletlinks the customer to page SH (see FIG. 57) which is a stripped downversion of the home page. FIG. 13 shows the navigational flow from pageSH, and is self-explanatory. Data entries other than locational dataresults in the customer being looped back to page SH.

FIGS. 14 and 15 illustrate the navigational flow from the “chooselocation” pages CL1-CL4. An exemplary screenshot of CL1 is shown in FIG.38( a). Referring to FIG. 38( a), CL1 lists a plurality of branchlocations 332 that meet the zip code criterion provided by the customer.Because CL1 is reached when the vehicle type for the reservation isknown, each branch listing 332 also lists that branch's status as to theavailability of the selected car (see vehicle availability status column336). Each branch listing 332 also lists that branch's distance from aselected point in the zip code provided by the customer (see branchdistance from zip code column 334). Preferably, CL1 lists not only thebranches that are acceptable for selection as determined from thecurrent reservation data (i.e., open branches having the selectedvehicle available at the selected time) but also branches that areunacceptable for selection based on current reservation data (i.e., thebranch listings denoted as “closed” or “sold out”). While such branchesare not acceptable for selection via link 338, the customer may desireto change other reservation data to make a particular locationacceptable. For example, by selecting the link 342, a customer will belinked to a branch details page allowing the customer to possibly changereserve time (steps 14.14-14.16).

For each branch listing 332 where the selected vehicle is available, a“select” link 338 is provided nearby that allows, upon selectionthereof, the customer to select the branch to which the “select” linkcorresponds. No “select” links are provided for branches where eitherthe selected vehicle is unavailable or the branch is closed during theselected start time. Each branch listing also includes a “view branchdetails” link 342 that, upon selection, links the customer to a page (aBD page) that provides more details as to the pertinent data for thebranch (i.e. hours of operation, rental policies, shuttle service (ifavailable), etc.) and if a vehicle has not been selected also presentsthe customer with a listing of available vehicles. Furthermore, a “next5/prev 5” link 340 is also provided (when the number of branch listingsexceeds a predetermined number, which is preferably however many branchlistings comfortably fit on the page). Upon selection of link 340, theCL1 page is redisplayed with the next 5 or previous 5 branch listings.

Another feature of the parent invention that can be seen on the CL1 pageis summary section 330. Summary section 330 provides the customer with arunning summary of reservation data submitted to processor 150. Summarysection 330 preferably includes a listing for L stage data 346 which canbe seen in FIG. 38 as not yet existing, T stage data 348 which is thestart date/time and end date/time provided by the customer, V stage data350 which is the vehicle type data provided by the customer, A stagedata 352 which is the age data provided by the customer, and RI stagedata 354 which is the renter information provided by the customer. Thesummary section 330 also includes, for each reservation data type forwhich a complete data value has been received, a nearby (preferablyadjacent as shown) “editing” link 360. “Editing” link 360 is selectableto initiate a revision to the data with which the link is associated.The “editing” link provides the parent invention with a uniqueuser-friendliness and flexibility that allows customers to easily reviseany errors that may have been made when entering data or quicklyimplement changes of mind. In the example of FIG. 38, it can be seenthat only the T stage data 348 has been provided by the customer, and assuch, an “editing” link 360 is situated adjacent thereto.

While it is preferred that the summary 330 include a separate edit linkfor each listed data value, this need not be the case. By providingseparate edit links for each listed data value, the user-friendliness ofthe summary section 330 is improved because the customer can initiallydetermine how to best initiate a data value revision. However, lesspreferred edit link implementations can be used, such as a single editlink within the summary section 330 that is selectable to initiate arevision for any of the listed data values, or the like.

Furthermore, summary section 330 preferably includes a progress marker344 which notifies customers of how far along they are in thereservation booking process. In the example of FIG. 38( a), progressmarker 344 notifies the customer that the process is 20% complete(preferably the stages considered by the progress marker are T, V, L,RI, and a verification stage). However, as would be apparent to those ofordinary skill in the art, more or fewer stages could be considered incalculating the percentage complete for the progress marker. As can beseen in connection with the other screenshots shown in the figures, thesummary section 330 provides a useful tool through which customers canoptimize the reservation booking process.

FIG. 40 illustrates CL3 which closely matches CL1, except column 334 isnot included (because the customer has not provided a zip code). FIG. 41also shows an example of another hyperlink that may appear on either CL1or CL3—the “check other vehicles” link 360. Whenever the selectedvehicle is unavailable at one of the branch listings 332, a “check othervehicles” link 360 is preferably provided as an action item for thebranch that is selectable to both select the corresponding branchlocation and initiate a “change vehicle” edit.

Also, FIG. 38( b) illustrates a link 550 that can be provided on any ofthe CL pages (see FIGS. 38( a), 39, 40, and 41) for restricting the listof branch locations in an area to only branch locations designated asairport branches. Upon user selection of the “show airport locations”link 550, the page of FIG. 64 is presented the user. As can be seen inFIG. 64, the branch locations available for selection have beenrestricted to only the airport locations meeting the original searchcriteria. It is preferred that the page of FIG. 64 also include a “showall locations” link 552 that returns the user to the full range ofbranch locations that are available for selection (as presented to theuser prior to the user's selection of link 550). Because many rentalvehicle customers are interested in renting vehicles at airport branchlocations as those locations are most convenient for airport travelers,this “show airport locations” link 550 provides a valuable tool inattracting and retaining air travelers to the rental vehicle website asa result of the increased user-friendliness. Further still, this featureof the invention is particularly valuable for a reservation bookingentity that has thousands of branch locations (with each city with amajor airport having numerous branch location) because it allowscustomers who arrive in a city via air to quickly identify theappropriate branch location for a reservation (the airport branchlocation) without the need to sift through several other branchlocations that are located in the city. It is worth noting that a branchlocation can encompass any individual rental office or facility of arental company, a rental franchise location, a rental retail locations,satellite location, or any other location at which a rental vehicle maybe procured. An airport branch location designates a branch locationnear an airport (or often on airport grounds) that is designated for orprimarily dedicated to servicing customers who arrive from the nearbyairport.

FIG. 14 illustrates the navigational path starting from either CL1 orCL3. If the customer selects one of the listed branches, the servletfirst checks whether the selected branch is flagged as an airportbranch. If so, the servlet checks whether the return time for thereservation is after the branch's closing time. If the return time ispost-closing, the customer is linked to an “after hours” (AH) page (seeFIG. 58) which provides the customer with the option of either acceptingthe selected branch's after hours return policy (continue to step 14.6)or initiating a change to the reservation time (link to page ChT2,described in more detail below). At step 14.6, a VD1 page (see FIG. 44)is displayed which notifies the customer of important vehicleinformation such as base rate and total rental cost.

If step 14.2 determines that the selected branch is not an airportbranch, then the servlet proceeds through steps 14.7-14.11. In the eventthe selected branch offers an after hours return policy, the steps14.8-14.11 are performed (which essentially mirror 14.3-14.6 exceptnon-airport page versions are displayed). If there is no after hourspolicy at the selected branch and the return time is after closing,steps 14.11-14.13 are followed.

Another selection possibility from CL1 or CL3 is the selection of a“view branch details” link 342. If a link 342 is selected, then thecustomer is linked to a “branch details” page (either BD2 or BD3depending on whether the selected branch is an airport branch —see FIGS.47-48). The BD pages provide detailed information about the branchcorresponding thereto.

Other selection possibilities from CL1 or CL3 are derived from the“editing” links 360 in the summary section 330. Because it is preferredthat default values be used for T data and A data in the absence ofmodification thereof by the customer, summary sections 330 will alwaysinclude “editing” links 360 corresponding to changing the reservation'stemporal data and changing the customer's age. Selection of those“editing” links will link the customer to pages SH (see FIG. 57) and ChA(see FIG. 56) respectively. Also, because CL1 and CL3 will always bereached when a vehicle type has been selected, the “editing” link 360corresponding to V stage data will also be present and selectable tolink the customer to a “choose vehicle” page (CV1) (see FIG. 42).Furthermore, in the event that the renter information is known (theconditionality of the “change RI” path is indicated by the dashedlines), an “editing” link 360 corresponding thereto will be present inthe summary section 330 and selectable to link the customer to a changerenter information page (RI)—see FIGS. 50( a)-(b). Renter information(RI) (see FIG. 50 for an example of information desired) can be obtainedeither through data entry from page RI or through a customer profilelearned either from customer registration/log-in or cookie recognition.Further, any customer profiles used with the parent invention may alsoinclude parameters such as “preferred vehicle type”, “preferred branchlocation” or the like to further expedite subsequent reservationtransactions.

FIG. 15 illustrates the navigational path starting from CL2 or CL4. Anexemplary screenshot for CL2 is shown in FIG. 39, and an exemplaryscreenshot for CL4 is shown in FIG. 41. Like CL1, CL2 includes column334 because CL2 is reached when the customer provides a zip code infield 302 of page H. Also, because no vehicle information is known, alocation status column 362 is provided that identifies whether anyvehicles are available at the listed branches and whether the branch isopen for business at the selected start date/time. Also of note is theairplane icon 364 that appears beside any branch listings 332 that areflagged as airport branches to notify customers of which branches areairport branches.

CL4, shown in FIG. 41, is highly similar to CL2 except column 334(distance of branch from zip code) is not shown because no zip code wasentered by the customer when reaching CL4. Like CL2, CL4 includes abranch status column 362.

FIG. 15 illustrates a navigational path for the parent inventionstarting from either page CL2 or CL4. Steps 15.2-15.13 of FIG. 15parallel steps 14.2-14.13 of FIG. 14, with the exception that CV pagesare reached at steps 15.6 and 15.11 instead of VD1 pages (as in FIG.14). Furthermore, because no vehicle is selected, steps 15.15-15.17 linkthe customer to a BD page that allows the customer to make vehicleselections therefrom.

FIGS. 16 and 17 illustrate navigational paths for the parent inventionstarting from the CV pages, and are readily understood upon reading theCV page information below. Exemplary screenshots for CV1 and CV2 areshown in FIGS. 42 and 43 respectively—the only difference being that CV1corresponds to a reservation where the selected branch is not an airportbranch and CV2 corresponds to a reservation where the selected branch isan airport branch. Both CV1 and CV2 include a vehicle inventory list forthe selected branch. Both acceptable vehicle types (those with a selectlink 376) and unacceptable vehicle types (those without a select link376) are preferably listed.

Each vehicle listing 370 identifies the vehicle type (economy, compact,etc.), a link 372 to “view vehicle details”, a description of the makesand models for the class, a price quote, and when the vehicle isavailable, a “select” link 376. The price quote preferably includes botha daily rate for the vehicle and a total price listing reflective of thedaily rate times the number of reservation days (known from T data) plusany surcharges, taxes, etc. By displaying both the daily rate and totalprice, the customer is made more fully aware of price issues for thereservation. With this feature of the parent invention, when thecustomer desires a particular vehicle, he/she can learn if any otherbranch locations (some of which may be sufficiently nearby) offer thedesired vehicle. If a listed vehicle is unavailable, a link 378 isprovided which, upon selection, allows the customer to both (1) selectthe vehicle and (2) link to a choose location page (CL1 or CL3). CV1 andCV2 also both include summary section 330.

FIGS. 18 and 19 illustrate the navigational paths starting from thepages VD1 and VD2 respectively. FIGS. 44 and 45 illustrate examples of“vehicle details” screenshots for VD1 and VD2 respectively. Referring toFIG. 44, VD1 includes information listing 390 that contains detailedinformation about the selected vehicle. This detailed informationpreferably includes a make/model description, a listing of vehiclefeatures (such as A/C, stereo, engine, number of doors, etc.), a pricequote (preferably both a daily rate and a total cost), etc. Links 392and 394 allow the customer to link to a “vehicle details” page for thenext smaller or next larger vehicle classes respectively. The “all” link360 between links 392 and 394 corresponds to a “change vehicle” link.The “select” link 398 is provided for customers who, upon reviewing thedetails shown in listing 390, wish to select the shown vehicle. VD1 alsoincludes a summary section 330.

VD2 includes a listing 390 of vehicle details for a vehicle that isunavailable for selection. VD2 is typically reached when link 392 or 396of VD1 is selected and calls up a vehicle class that is unavailable. VD2also preferably includes summary section 330.

FIGS. 20-23 illustrate navigational paths starting from various “branchdetails” (BD) pages and are readily understood upon reading the BD pageinformation below. An exemplary BD1 is shown in FIG. 46. BD1 showspertinent branch information for a selected non-airport branch when novehicle has been selected. Listing 400 includes pertinent branchinformation such as operating hours and address. Because no vehicle hasyet been selected, BD1 also includes a vehicle menu 402 that lists thevehicle inventory for the selected branch. Menu 402 is similar to aminiature “choose vehicle” page. Each vehicle listing includes a pricingcolumn 380 and a “selection” column that includes links 376. The“select” links 376 are selectable to submit the vehicle correspondingthereto as the V data for the reservation. Each entry in the pricingcolumn preferably includes both the daily rate and the total cost asexplained above. BD1 also includes a summary section 330. BD4, shown inFIG. 49, closely corresponds to BD1, with the exception that theselected branch is an airport branch, and as such, the information inlisting 400 is preferably slightly different.

An exemplary BD2 screenshot is shown in FIG. 47. BD2 is reached when avehicle has already been selected. As such, BD2 includes a “selectedvehicle information” listing 408 which is similar to a miniature VD1page. Listing 408 includes pertinent information about the selectedvehicle, a link 360 that is selectable to link to a CV page, and a link410 selectable to continue the process with the selected vehicle. Thepertinent information in listing 408 preferably includes both a dailyrate and a total cost as explained above. BD2 also includes a summarysection 330. BD3, shown in FIG. 48, closely corresponds to BD2 with theexception that the selected branch is an airport branch, and as such,the information in listing 400 is slightly different.

FIG. 24 illustrates a preferable navigational path starting from the“enter renter information” page (RI) and is readily understood uponreading the RI page information below. An exemplary RI page is shown inFIGS. 50( a) and 50(b). The RI page preferably includes a field 420 inwhich the renter's name can be entered, a field 422 for the renter'sphone number, a field 424 for the renter's e-mail address, a field 426for the renter's credit card type, and a plurality of fields 430 foradditional information that is generally needed from the customer by arental car company employee working at the counter of the branchlocation when the customer actually arrives to pick up the rental car. A“continue” link 428 submits any entered data to the processor 150. Nofields in RI need to be required, however, it is preferred that thename, phone number, and credit card type fields be flagged as requiredfields. The RI page also includes a summary section 330.

FIGS. 25 and 26 illustrate preferred navigational paths for the parentinvention starting from a “verify” (V) page and are readily understoodupon reading the V page information below. FIGS. 51 and 52 are exemplaryscreenshots for an non-airport version (V1) and an airport version (V2)respectively of the “verify” page. Both V1 and V2 include a listing 440of pertinent information for the rental, such as important terms andconditions, after hours information, and a total cost estimate (theinformation in listing 440 may include additional airport-related datasuch as shuttle availability information). Summary section 330 isincluded in V1 and V2 to identify the data values for the differentreservation data types 346-354 that have been submitted to the processor150. Should the customer wish to revise any of the data entered for thereservation transaction, the “editing” links 360 are available. Link 442is a “booking” link that submits the reservation to the processor 150for final booking. Link 444 is a “cancel” link that cancels thereservation, and link 446 is an “upgrade” link that is selectable tolink the customer to a “vehicle details” page for the vehicle of thenext larger vehicle class.

In the event the customer decides that all information on the “verify”page is correct and the reservation is ready for booking, afterselection of the “booking” link 442, the customer is linked to a“confirmation” page. FIG. 27 illustrates the preferred navigational pathfor the parent invention starting from the “confirmation” page (Conf).FIG. 53 illustrates an exemplary screenshot for Conf. The Conf pageincludes confirmation information 450, the confirmation information 450,and a confirmation number 498. A “print” link 452 is provided to allowthe customer to print out the reservation confirmation number and datavalues. A “create another similar reservation” link 454 is provided toallow the customer to repetitively make new reservations using thecurrent reservation data as the starting point (upon selection of link454, the customer is linked to a “verify” page wherein the reservationdata matches the current reservation data, and wherein the customer isprovided with the ability to, if necessary, modify the reservation datawhen making the new reservation). Additional preferable links on theConf page include a “speed your time at the counter” link 456 thatappears if the customer did not fully fill out fields 430 in the RIpage. Link 456 is selectable to return the customer to page RI or ashortened version thereof that includes only the fields 430. Also, theConf. Page preferably includes a “modify/cancel” link that isself-explanatory.

The preferred navigational paths starting from the “change time” pagesare shown in FIGS. 28-29 and are readily understood upon reading the“change time” page information below. An exemplary ChT1 page is shown inFIG. 54. ChT1 is reached when a customer has opted to change thereservation time after already selecting a non-airport branch location.Listing 470 preferably provides business hours information for theselected branch and possibly additional information such as an address.Fields 304-310 are provided to update the reservation time. Link 472 isselectable to submit the updated reservation time. “Show more locations”link 360 is analogous to a “change location” edit link 360 shown insummary section 330.

An exemplary ChT2 page is shown in FIG. 55. ChT2 is highly similar toChT1 except ChT2 is reached when the selected branch is an airportbranch. Also, ChT2 preferably does not include a “show more locations”link 360.

FIG. 30 illustrates the preferred navigational path for the parentinvention starting from the “change age” page (ChA), an example of whichis shown in FIG. 56. Referring to FIG. 56, from field 480 of the ChApage, the customer can change the age value for the reservation—preferably to one of three groups 25+(unrestricted), 21-24 (somevehicle restrictions exist), and 18-20 (only allowed to rent a vehiclein New York). The ChA page also preferably includes the summary section330. As shown in FIG. 30, the navigational path from the ChA pagerequires additional decision-making based on age (given the new agedata, is the customer eligible to rent any vehicles? the selectedvehicle?).

FIGS. 58 illustrates a preferred screenshot for the “after hours” pagereached when the selected return time for an airport branch is afterclosing. The AH page includes a listing 490 that notifies the customerof the after hours return rules. The AH page preferably further includesa “change time” link 360 that is selectable to link to a ChT page, and a“continue” link 492 that is selectable to indicate that the customeraccepts the after hours conditions. Once again, the AH page includes asummary section 330.

FIGS. 59-61 are exemplary screen shots for apology conditions. APOL1,shown in FIG. 59, includes apology field 494 that notifies the customerthat all vehicles at the selected location are sold out. Outside of thesummary section 330, a “try new dates” link 360 is provided along with a“search for a new location” link 360. Also, a “return home” link 460 isprovided. “Try new dates” link 360 links the customer to a ChT page,“search for a new location” link 360 links the customer to a CL page,and link 460 is selectable to link the customer to the home page (H).APOL1 also includes summary section 330.

APOL2, shown in FIG. 60, closely tracks APOL1 except a “search for a newlocation” link 360 is not provided (outside of the edit link 360corresponding to a location change in summary section 330).

Also, APOL3, shown in FIG. 61, listing 496 notifies the customer thatage restricts him/her from vehicle rental. Link 460 is a “return home”link.

FIG. 62 illustrates an exemplary “reservation cancellation” page(Cancel) that includes “cancel” link 498, “don't cancel” link 500, andsummary section 330.

From the home page of FIG. 37 (as well as most other pages), the parentinvention provides a branch location search tool via the “locations”link 520 of FIG. 37. User selection of link 520 causes display of thepage shown by FIG. 65 on the user's computer. From the page of FIG. 65,a user can browse branch locations until finding the appropriate one forreservation. With reference to FIG. 65, field 522 is provided for userentry of a postal code or city name. Field 524 is provided, preferablyas a dropdown menu, so that the user can identify the country in which areservation is sought. The data provided in these fields serves assearch criteria that the system uses to query the database and retrieveall branch locations meeting that user-provided criteria.

Once the database has returned branch location data meeting thiscriteria, the page of FIG. 66 is presented to the user. FIG. 66 listseach branch location's name 526 and city/state 528 meeting the searchcriteria. Each entry also has a corresponding “details and map” link 530that the user can select to learn more about the branch locationassociated therewith. Further, the “new search” link 532 is preferablyprovided to take the user back to the page of FIG. 65 upon selection.

FIG. 67 illustrates the page presented to the user upon selection of a“details and map” link 530. The page of FIG. 67 presents additionalinformation about the pertinent branch location, including name andaddress 534 and hours of operations 536. “Map” link 540 is selectable bythe user to display a road map around the branch's geographic location.Also, it is preferred that a “search again” link 532 be present toprovide the same functionality as the “new search” link of FIG. 66.Lastly, the page of FIG. 67 provides a “reservation” link 538 thatallows the user to select the pertinent branch location and directlyjump into the reservation process using the pertinent branch location asthe selected branch location. The user is preferably entered into thenavigational path as if the user has selected the branch location 534and any other reservation data that the user may have previouslyprovided. Thus, the preferred embodiment of the parent inventionprovides users with yet another flexible technique for identifying abranch location of interest and beginning the reservation process.

Another aspect of the parent invention is the concept of “deep-linking”customers into a stage of the reservation booking process commensuratewith the conditions of a promotion they have selected or a corporateaccount they are using. When a customer selects a promotional link (link318 shown in some of the screenshots, including H and Conf), it istypical that the promotion has one or more conditions associatedtherewith. For example, a rental car company may offer a promotion for areduced rental price for a particular type of vehicle during a specifiedtime period. To promote the promotion, the rental car company mayprovide hyperlinks on other websites through advertising or the like, ormay include promotional links on its own website to attract customers.

When a customer selects such a promotional link to initiate areservation transaction, it is preferable that the user begin thereservation transaction with the reservation data corresponding topromotional conditions set equal to those conditions, to thereby avoidunnecessarily requiring the customer to enter such data himself/herselfor creating a situation where the customer may accidentally enter datathat violates the conditions of the promotion. For example, if apromotion has a condition that the type of vehicle must be “standard”,it is preferable that the customer, upon selection of a linkcorresponding to that promotion, be linked into the reservation bookingprocess such that the vehicle type is automatically set to “standard”.FIG. 31 illustrates this “deep-linking” concept. In one example, apromotion has one condition: the vehicle type must be “economy”. Uponselection of an icon or link associated with that promotion, thecustomer is preferably linked to a state where V has been automaticallyset to “economy”, and the remaining options are to choose a time andlocation. In another example, a promotion has two conditions: thevehicle type must be “luxury” and the duration of the reservation muststart on Jul. 5, 2002 and end of Jul. 6, 2002. Upon selection of an iconor link associated with that promotion, the customer is preferablylinked to a state where V has been automatically set to “luxury” and Thas been automatically set to “Jul. 5, 2002 through Jul. 6, 2002”, andthe only remaining option to choose is location.

Furthermore, as is apparent from the preceding navigational paths andscreenshots, the parent invention provides customers with unparalleledflexibility in entering the data necessary to book a reservation,including the ability to possibly change one or more promotionalconditions. To avoid situations where a customer unknowingly modifies adata value such that a promotional condition is violated, the process ofFIG. 32 preferably runs after each data submission when the customer ison a promotional path. If a promotional icon has been selected, theservlet checks whether any of the data provided by the customer violatesany of the promotion's conditions (step 32.2). If no violation is found,any remaining reservation data corresponding to a promotion condition isautomatically set in accordance with the promotion condition (step 32.4)and the customer is deep-linked into the website of the parent inventionto a page that is appropriate given the reservation's current datastatus.

If a violation is found, the customer is linked to a “notice” page (step32.3). The “notice” page informs the customer which data value violatesthe conditions of the promotion and why. FIG. 33 illustrates thenotification process wherein the customer is given an option to revise.The notice page shown in FIG. 63( a) includes a notification 401 that apromotional condition has been violated, including an identification ofwhich reservation data violates the condition. Preferably, notification401 also identifies what the promotion condition is. A “change” link 403is provided to allow the customer to revise the out-of-promotion data toin-promotion data and a “continue” link 405 which allows the customer tocontinue the reservation outside the promotion condition.

Other examples of potential promotional conditions that the servletshould be designed to handle are conditions that are ranges ofacceptable data values, such as a promotion that may be taken advantageof any day during the month of August. Although the automatic settingaspect of deep-linking would be inapplicable to such range-basedconditions because more specific time information is needed from thecustomer, the process of FIGS. 32 and 33 should still run to identifywhether the customer has entered time data not in the condition's range.

FIGS. 34-36 illustrate the same “deep-linking” concept as applied tocorporate accounts. Many businesses or groups of people set up so-called“corporate accounts” wherein a profile is established for thebusiness/group. Data stored in a profile may be the types of vehicleseligible to be rented within the parameters of the corporate account,renters whose age and personal information are remembered between visitsto the website, etc. The profile data may also include graphicalenvironment settings, such as “co-branding” of the website pages so thata business logo, trademark, or the like of a business partner with acorporate account is displayed on the web pages presented to a user.With reference to FIG. 37, a business partner's logo/trademark can bemade to appear in field 317 as part of this co-branding process.“Co-branding” provides users with comfort in knowing that they have notstrayed off the corporate account path for the reservation transactionas a result of the reassuring sight of the familiar companylogo/trademark and also provides business partners with improvedvisibility for their name and logo.

Further, the profile data may include customer-preferred settings forfeatures such as e-mail notifications (the addresses to whichconfirmation/notice e-mails are sent, whether promotional offer e-mailswill be sent or withheld, etc.).

When a customer accesses the website of the parent invention andindicates a desire to use his/her applicable corporate account (seefield 316 of page H), the “deep-linking” concept of FIG. 34 can be used.Also, the steps shown in FIGS. 35 and 36 parallel those of FIGS. 32 and33 for promotional “deep-linking”. FIG. 63( b) illustrates a page forwhen reservation data involves a corporate account parameter. In thisexample, it can be seen that “full size” vehicles are unavailable forreservation through the applicable corporate account because they are“not in [the] agreement”. Optionally, the notice page of FIG. 63( b)also includes links 403 and 405 as shown in FIG. 63( a) (not shown).

Another technique for providing corporate account deep-link access asshown in FIG. 34 is to provide business partners having a corporateaccount with a uniform resource locator (URL) that the websiterecognizes as being associated with a particular business partner andwhose invocation results in gaining deep-link access to the website inaccordance with that business partner's corporate account parameters.The URL is preferably provided to the business partner via e-mail,however any other known mode of communicating data can be used. Also,while it is generally expected that an employee of the business partnerwould incorporate a URL received via e-mail on, for example, thebusiness partner's intranet site, it is also possible that an employeeof the reservation booking entity would be asked to install the URLdirectly on the business partner's intranet site himself/herself.

Different fields of the URL can identify different pieces of informationthat the website may use to find the appropriate page at which to dropthe customer into the reservation website. For example, the URL caninclude a field for a corporate or customer account. The URL may includea field that identifies a preferred branch location from which to rent avehicle. Essentially, the URL may include any piece of information thatis useful for deep-linking the customer into the reservation process.Further, it is worth noting that the URL can include a combination ofdata values for various pieces of reservation information for ahighly-focused deep-link. For example, a deep-link URL that is providedto a repeat user can be as follows:

http://www.enterprise.com/car_rental/deeplinkmap.do?BID=X&cust=12345&gpbr=abcwherein the URL includes a “BID” field for identifying the parametersthat can be expected in subsequent fields of the URL and how thoseparameters should be processed, a “cust” field for identifying anaccount number, and a “gpbr” for identifying a preferred branchlocation. Using the data values of X, 12345, and abc for theseparameters, the customer who invokes this URL can be deep-linked intothe reservation process at a page wherein the branch location hasalready been entered (the location that corresponds to the code “abc”)and wherein any rates that are available to account number 12345 aremade available.

This URL can be placed on the business partner's computer system,preferably the business partner's intranet site or a portion of thebusiness partner's internet site having restricted access (so that thebusiness partner may exert some control over who gains access to thecorporate account). However, it should be understood that such URL linkscan also be placed on general access Internet websites. Also, ratherthan invoking the URL from a link placed on the business partner'sintranet site, an employee of the business partner may also invoke theURL from a link in an e-mail sent directly to that person by thereservation booking entity. Such links are valuable because they providesingle click deep-link access to the reservation booking website.However, other less time efficient means of invoking the URL can stillbe used, such as typing the URL into a web browser. Therefore, from theintranet site or the like of a business partner, a user can gain directdeep-link access to the reservation website by clicking on a hyperlinkthat deep-links that user to the reservation website. Such a hyperlinkprovides a large degree of user-friendliness in that the user isalleviated of the need to remember a corporate account number in a fieldsuch as field 316 of FIG. 37.

Also, repeat users other than members of business partners (e.g.,ordinary customers who wish to reserve a rental vehicle) can takeadvantage of the deep-linking aspect of the preferred embodiment of theparent invention. Accounts, or profiles, can be created for suchcustomers and stored in a database (e.g., database 208 of FIG. 6).

The customer account preferably includes a plurality of customerparameters that relate to personal information about the customer andpreferred reservation settings. The personal information would includeinformation such as name, address, telephone number, e-mail, etc. Thispersonal information can include any piece of information shown on theRI page of FIGS. 50( a) and (b), and may include other types of personalinformation. Examples of preferred reservation settings that can beincluded in the customer account include a “favorite” branch location(e.g., the branch location at which the customer generally prefers torent vehicles), a “favorite” vehicle type, a “favorite” airport (e.g.,the airport at which the customer will most often need rental vehicletransportation, whether and what type of insurance coverage is desired,and may also include second, third, etc. “favorites” for these criteria.Further, the customer account parameters can define the type ofmarketing information that the customer receives (e.g., whether e-mailnotices of promotional offers are provided to the customer, etc.)

The customer account can obtain this data through a customer-interactivepage presented to the customer, wherein the customer is prompted forsuch information and, after providing the requested data, submits theparameter information to the database for storage. FIG. 83 illustrates apreferred navigational flow for this process. The process begins when acustomer either requests access to his/her account/profile or requeststo create a new account/profile. Access can be provided via a link on adisplayed page. For example, links can be provided on the home page orother pages of the reservation booking website that are effective, uponselection, to display a page that allows a customer to create a profileand/or display a page that allows a customer to review/modify his/herstored profile data (see. e.g., link 9002 of FIG. 90).

FIG. 84 depicts a preferred page 8400 for customer entry of basic renterinformation for a customer profile. Preferably the various data entryfields of page 8400 correspond to the data requested on the preferredRenter Information page (see FIGS. 50( a) and (b)). Button 8402 iseffective upon customer selection to save any data entered on page 8400and display “Main Profile” page 8500 on the customer's computer. Link8404 is effective upon customer selection to save any data entered onpage 8400 and display an “Add Another Renter” page on the customer'scomputer. Preferably, the “Add Another Renter” page will appear likethat shown in FIG. 84, although field(s) may be provided thereon forentering a UserID and/or password for the “another renter” to enablefast loading of the another renter's stored profile data (if available)into the “other renters” section of the customer profile.

Once a user has added another renter to his/her profile, it is preferredthat at least one page within the reservation path encountered by thatuser after accessing his/her profile will provide the user with theoption of booking a reservation on behalf of one of the “anotherrenters” stored within his/her profile.

It is worth noting that if a customer has multiple renters associatedwith his/her profile, then it is also preferred that a page (not shown)within the flow of FIG. 83 also display a summary of reservation historyfor not only that customer but also the other renters within his/herprofile. This history preferably includes recent closed reservations,pending reservations, and pertinent data thereto (such as a reservationnumber and the name of the customer in whose name the reservation hasbeen booked.

In an alternative embodiment, “another renter” information can be pushedto a customer's profile from the profile of that “another renter”. Insuch cases, the main profile page 8500 would include a link “Grant Useand Access to My Profile Information to a Another Authorized ProfiledCustomer” (not shown). Upon selection of such a link, “another renter”customer would have the opportunity to identify the User Name and/orPassword of the customer to whom reservation booking authority will begranted. After entering the appropriate User Name and/or Password, the“other renters” section of the profile for the customer to whomauthority was granted will be populated with profile data for the“another renter”.

Button 8406 is effective upon customer selection to clear any dataentered by the customer on page 8400. Lastly, link 8410 is effectiveupon customer selection to display a page (not shown) on the customercomputer that explains the benefits of creating a customer profile withthe reservation booking website. This “Learn More” page preferablyincludes a link to page 8400 as well as a “no thanks” link that returnsthe customer to the page he/she left prior to arrival in the customerprofile navigational path of FIG. 83.

After the customer has entered renter information on page 8400 andselected button 8402, the Main Profile page 8500 of FIG. 85 ispreferably displayed on the customer's computer. Main Profile page 8500preferably includes three sections, a “Renter Information” section 8502,a “Favorite Locations” section 8506, and an “Other Renters” section8520. Exit button 8530 is customer selectable to return the customer tothe page that was displayed prior to the customer's arrival in theprofile navigational path of FIG. 83.

Renter Information section 8502 preferably includes a display summary ofthe customer information entered by the customer on page 8400. Link 8504is also preferably present in section 8502 to allow the customer toreturn to page 8400 to modify that customer information.

Other Renters section 8520 preferably displays a list of one or moreother people (e.g., 8524 a, 8524 b, 8524 c, for whom the customer cancreate reservations. “Modify” links 8526 are preferably providedalongside each of the additional renters. Each “modify” link 8526 ispreferably customer selectable to allow the customer to change thepertinent personal information for the additional renter associatedtherewith. “Delete” links 8528 are also preferably provided alongsideeach of the additional renters, wherein each “delete” link 8525 iscustomer selectable to effectuate a deletion of the corresponding listedname from the “other renters” list. “Add a New Renter” link 8522 ispreferably customer selectable to display the “Add Another Renter” pagediscussed above.

Favorite Locations section 8506 preferably displays a list of one ormore branch locations (8510 a, 8510 b, 8510 c, that the customer hasidentified as “favorite” or “preferred” branch locations from which torent rental vehicles. Each listed “favorite location” is preferablyaccompanied by a “modify” link 8512 and a “delete” link 8514. Each“modify” link 8512 is customer selectable to display a “Modify FavoriteLocation” page 8800 (shown in FIG. 88) for the corresponding listedfavorite branch location. Each “delete” link 8514 is customer selectableto delete the corresponding favorite branch location from the list ofsection 8506.

An alias or nickname 8516 is preferably displayed for each listedfavorite branch location 8510. In the example of FIG. 85, the alias 8516a for favorite branch location 8510 a is “Home”. The alias 8516 b forfavorite branch location 8510 b is “Work”, and the alias 8516 c forfavorite branch location 8510 c is “Vacation House”.

Furthermore, each listed favorite branch location preferably includes acolumn 8518 for listing a preferred vehicle class for each listed branchlocation. As can be seen in FIG. 85, there is no associated “preferredvehicle class” 8518 a for “Home” branch location 8516 a. However, a“Compact” vehicle class is the associated “preferred vehicle class” 8518b for “Work” branch location 8516 b, and a “Convertible” vehicle classis the associated “preferred vehicle class 8518 c for “Vacation House”branch location 8516 c. It should be noted that in alternativeembodiments, the customer's preferred vehicle class” could be universalto all branch locations. Further still, the “preferred vehicle class”need not be broken down by favorite branch location. For example, withinthe customer profile, a customer can identify a preferred vehicle classfor work-related rentals as well as a preferred vehicle class forvacation/leisure-related rentals.

Section 8506 preferably further includes an “Add a New Location” link8508. Link 8508 is preferably customer selectable to display page 8600of FIG. 86. Page 8600 is a branch location search page that includes afield 8602 in which the customer can enter search criteria for findingone or more branch locations. For example, the customer can enter acity, state, and/or zip code of an area of interest. Customer selectionof the “Find It” button 8604 is effective to conduct a search of branchlocations in database 206 that match the criteria entered in field 8602.Once the search results are obtained, the “Choose Favorite BranchLocation” page 8700 of FIG. 87 is preferably displayed.

The Choose Favorite Branch Location page 8700 preferably lists aplurality of branch locations 8702 a, 8702 b, . . . that match thesearch criteria entered in field 8602 of page 8600. Each listed branchlocation 8702 preferably includes (1) a selection mechanism such as aradio button 8704 for selecting that listed branch location to be savedas the customer's favorite, (2) an identification 8706, 8708, and 8710of each listed branch location's address, city, and state, (3) a “ViewMap” link 8712 that is customer selectable to display a map (not shown)that depicts the branch's street location, and (4) an alias/nicknamefield 8714 in which the customer can enter an alias or nickname for thebranch location. The alias/nickname entered by the customer in field8714 is what will be displayed as alias/nickname 8516 in section 8506 ofpage 8500.

Field 8716 is preferably provided to associate the branch locationselected by radio button 8704 with a preferred vehicle class. Byassociating the favorite branch location with a preferred/favoritevehicle class, the customer has the ability to further streamline thereservation creation process by bypassing not only the RenterInformation page and the Choose Location page, but also the ChooseVehicle page. Button 8718 is customer selectable to call up a drop downmenu that lists the vehicle classes available for customer selection.

“Save and Return to Main Page” button 8722 is preferably customerselectable to save the selected branch location as a favorite branchlocation in the customer's profile/account and return the customer to anupdated page 8500 (any branch locations that are newly designated as afavorite branch location will thereafter be listed in section 8506 ofFIG. 85). “Save and Add Another Location” button 8724 is preferablycustomer selectable to save the selected branch location as a favoritebranch location in the customer's profile/account and return thecustomer to page 8600 of FIG. 86. From page 8600, the customer can begina search for a new favorite branch location. “Cancel” button 8720 ispreferably customer selectable to return the customer to page 8500 ofFIG. 85 without making any changes to the customer's list of favoritebranch locations. If the customer's search of branch location did notfind the branch location(s) of interest, then the customer can enter newsearch criteria in field 8726 to conduct a new branch location search.“Find It” button 8728 is preferably provided for customer selection toinitiate such a new search.

As can be seen in FIG. 88, the “Modify Favorite Location” page 8800,which can be reached via link 8512 on page 8500, includes a displaysection 8802 that identifies the address for the favorite locationsubject to modification. Page 8800 further includes a field 8804 inwhich the user can enter the location's nickname or alias. Furtherstill, page 8800 preferably further includes a field 8806 in which theuser can enter the user's preferred vehicle class for that location. Theuser can preferably access a dropdown menu of vehicle types availablefor selection via button 8808. Button 8810 is effective upon userselection to cancel any modifications entered by the user on page 8800,and button 8812 is effective upon user selection to save themodifications entered by the user within the user's profile.

Further, with reference to FIG. 83, a personal data page can be providedwherein the customer provides information on preferences such aslanguage (English, French, German, etc.), country of origin, home pageappearance, email settings, etc.

FIG. 89 depicts an alternate navigational path for customer profilecreation and management relative to the path of FIG. 83. In FIG. 89, theinitial page that is displayed to the customer is page 8500 rather thanpage 8400. In the flow of FIG. 89, page 8400 is displayed if thecustomer chooses link 8504 in section 8502 of page 8500. The flow ofFIG. 89 is believed to be best suited for cases where a customer hasalready created a profile and is accessing his/her profile to reviewand/or modify it, whereas the flow of FIG. 83 is believed to be bestsuited for cases where a customer is creating a new profile.

If a customer profile includes one or more favorite branch locations,then the home page displayed to the customer (after the customer haslogged into his/her profile/account), is preferably the page 9000 shownin FIG. 90. Page 9000 includes a favorite branch location selectionsection 9004 that includes a field 9006 for selecting the favoritebranch location to be used in a reservation, a drop down menu 9012 forlisting each favorite branch location 9010 a, 9010 b, . . . stored inthe customer's profile/account, and a button 9008 for calling up dropdown menu 9012. Drop down menu 9012 preferably lists the favorite branchlocations by their alias/nickname (if available) and byaddress/city/state (if an alias/nickname is not available). However, itshould be noted that it is preferred that customers be required toprovide aliases for their favorite branch locations. Rather than usingdrop down menu 9012 for selection of a favorite branch location to beused in the reservation, section 9004 page 9000 can alternativelyindividually list each favorite branch location stored in the customer'sprofile/account together with an associated selection mechanism such asa radio button to effectuate possible customer selection thereof.Furthermore, section 9004 can be included on pages other than thehomepage, including but not limited to a Choose Location page. In short,section 9004 can be included on any page within the website'sreservation path that is reached before the customer has chosen a branchlocation for the reservation.

Alternatively to the process shown in FIGS. 83 and 89, the customeraccount/profile information can be obtained in an automated fashion bycreating accounts for new customers as they book reservations. Thecustomer account parameters may then change over time as the accountkeeps track of the customer's preferences for subsequently bookedreservations. Further still, at the verify stage or confirmation stagefor a reservation, a checkbox or the like can be provided on the verifyor confirmation page that upon selection by the customer causes anaccount to be created that stores the data provided by the customer inbooking the reservation as the account parameters.

For example, FIG. 91 depicts a preferred flow 9100 for creating acustomer profile from reservation data provided by the customer whencreating and booking a reservation. On the Verify page (e.g., FIG. 51 orFIG. 52), the Confirmation page (e.g., FIG. 53), the Renter Informationpage (e.g., FIGS. 50( a) and (b)), or even within the summary section330 of a displayed page, a link 9102 can be provided for customerselection to create a customer account/profile based on the reservationdata provided by the customer. Preferably, upon selection of link 9102by the customer, a customer account will be created wherein the customeraccount (1) stores the Renter Information provided during thereservation creation process as the profile's Basic Renter Information,(2) stores the branch location for the reservation as the profile's“favorite” branch location, and (3) stores the vehicle class for thereservation as the profile's preferred vehicle class for the “favorite”branch location. Furthermore, rather than a single link 9102, any ofthese pages could be provided with a plurality of itemized linkscorresponding to different items of reservation information. Each ofthese itemized links would preferably be effective upon user selectionto store the particular item of data corresponding thereto (e.g., abranch location or a renter's address) in a customer profile. Forexample, a choose location page can include selectable “Add This BranchLocation to My Favorite Locations” checkboxes or the like alongside eachlisted branch location to effectuate efficient customer management ofhis/her profile.

Page 9200 of FIG. 92 is preferably displayed to communicate the creationof such a customer profile to the customer. Page 9200 is highlyanalogous to page 8500 of FIG. 85, and navigation from page 9200preferably proceeds as set forth for page 8500 in connection with FIG.83 or FIG. 89. In sections 8502 and 8506, the reservation data providedby the customer will be displayed in the appropriate fields as set forthabove. As with page 8500, the customer can utilize various “edit”,“modify” and “add . . . ” links to alter the profile data. However, indistinction with page 8500, page 9200 also preferably includes a field9204 in which the customer can establish a User Name for the customerprofile/account and a field 9206 in which the customer can establish aPassword for the customer profile/account. In alternative embodiments,the field 9204 and/or field 9206 can be displayed on an intervening pagebefore page 9200 is displayed. Furthermore, button 8530 is preferablyeffective upon customer selection to cancel the creation of the customerprofile and return the customer to the page from which he/she came.“Save and Exit” button 9202 is preferably effective upon customerselection to save the customer profile in database 208 and thereafterreturn the customer to the page from which he/she came.

While the examples of FIGS. 91 and 92 are described for creating newcustomer accounts based on reservation data provided during thereservation creation process, it is worth noting that button 9102 canalso be used to update existing customer profiles where the customer whois booking/has booked the reservation has pre-existing customer profile.In such cases, the data listed on page 9200 will preferably include notonly the new reservation data for the reservation but also pre-existingdata in the customer profile. Furthermore, to notify the customer of thenew information in the profile/account, some type of highlighting (e.g.,an arrow and/or marking such as highlighted or boldface text) ispreferably used to identifiably distinguish the old pre-existing profiledata from the new profile data.

Once an account has been created for the customer, subsequent visits bythe customer to the reservation booking website can take advantage ofdeep-linking. Through either recognition of a cookie that has beenplaced on the customer's computer or verification of a customer accountnumber provided by the customer (a customer having an account can beprovided with a customer number that identifies his/her account), acustomer can be deep-linked into the reservation booking process afterthe website has retrieved one or more of that customer's accountparameters. The page at which the customer is deep-linked into thewebsite may be a page at which the customer has already “selected” (byvirtue of the customer account-based deep-link), for example, aparticular branch location or vehicle type. Further, the customer ispreferably alleviated of the need to re-submit personal renterinformation because that information can be pre-loaded via thedeep-link. In a most preferred instance of customer account-baseddeep-linking, the deep-link takes advantage of all personal informationin the customer account that is necessary for booking a reservation, a“favorite” branch location in the customer account, and a “favorite”vehicle type in the customer account. With such a deep-link, the onlydata that a customer would need to provide to complete the reservationprocess is a pickup and return date and time. Further still, when acustomer has provided a list of first, second, third, and so on“favorite” branch locations or vehicle types, the page to which thecustomer is deep-linked can present a dropdown menu (see dropdown menu9012 of FIG. 90) of these preferred branch locations or vehicle types tothe customer for appropriate selection thereof.

Further still, customer account-based deep-linking can be used inconjunction with promotional deep-linking such that when a customerselects a promotional link (that may be provided via e-mail or posted ona page as a hyperlink), the resultant deep-link combines any promotionalsettings with any stored customer account parameters.

Further still, with the parent invention, travel agents can be providedwith an identifier, preferably their Airline Reporting Corporation (ARC)number, for use when accessing the reservation website. Similarly, thisARC number can be included in a URL provided to the travel agent fordirect deep-link access to the website. These identifiers can then bestored in a database. The identifiers can be associated with each travelagent individually or with the travel agent by way of a travel agency orsimilar such organization. Each reservation transaction completed by thetravel agent will then be associated with that particular travel agent(or travel agent organization) via the travel agent identifier. Thisassociation will be a valuable tool for determining any commissions thatthe travel agent/agency may be entitled to. Further, travel agents andtravel agencies can set up corporate accounts as described above toenable deep-linking access to the reservation website in accordance withany preferred settings and features that the travel agent/agency maywork out with the entity controlling the reservation website.

Yet another aspect of the parent invention lies in the ability to customdefine promotions and corporate accounts. As shown in FIG. 73, throughan interface 700, an account or promotion administrator can control aplurality of settings for the pages and rules of a promotion orcorporate account. These settings are then stored with the appropriateaccount in the database 208 for subsequent retrieval and processing.

Through the interface 700, it is preferred that the administrator beable to control nearly all aspects of the pages that a customer seesupon initiating a reservation transaction via a corporate or customeraccount or promotion. For example, the parameters set through GUI 700can control whether a marketing tile (see reference numeral 317 in FIG.37) is displayed on the user-interactive reservation pages. Similarly,the navigation bar (see reference number 706 in FIG. 37) that is presentin virtually all pages of the reservation process can be eliminated (itis expected that many business partners will prefer that the navigationbar be removed because its invocation will often cause users to departfrom the scope of the business partner's account—such as entering into acar sales realm of a website). Further still, on a CV page, the list ofavailable vehicle types for selection can be limited to one or moredifferent classes.

In the example of FIG. 73, which includes an exploded view of a GUI 700that can be presented to the administrator, it can be seen that theadministrator has control over several parameters, including (1) whetherthe navigation bar 706 is turned on or off, (2) the countries in whichthe corporate account/customer account/promotion is applicable, (3)whether the corporate account/customer account/promotion is limited to aparticular market, (4) and if limited to a particular market, the nameof the market (via a dropdown menu), (5) whether the age selectionfeatures of the pages should be turned on or off, (6) what vehicleclasses are available through the corporate account/customeraccount/promotion, (7) the rate reduction applicable to the corporateaccount/customer account/promotion, (8) whether co-branding should bedisplayed on the pages in connection with the corporate account/customeraccount/promotion, and (9) whether the damage waiver should be turned onor off for the corporate account/customer account/promotion. Moresettings can be controlled upon selection of a “more options . . . ”link 704. To save the settings to the database 208, the “save toaccount” link 704 is available.

It is preferred that an employee of the reservation booking entity serveas the administrator. However, it should be appreciated that theadministrator can also be an employee of the business partner. Through anetwork connection with the database 208, the GUI 700 can be displayedon the computer of a business partner employee, and the accountparameter data can be appropriately stored in the database.

In yet another embodiment of the present invention, the inventors hereinhave extended the reservation booking process to encompass generalaviation (GA) airports and Fixed Based Operator (FBO) services. As iswell-known, GA encompasses civil/private aviation other than scheduledcommercial airline flights. One significant aspect of GA is the privateaircraft/business aircraft market. These flights may take off and landfrom/to both regular commercial airports (such as O'Hare in Chicago, JFKin New York, LAX in Los Angeles, etc.) and GA-only airports, which aresmaller than the larger commercial airports. GA flights typically areserved by

Fixed Base Operators (FBOs) at the airport. As is well-known, FBOs(which may be a private company or municipal/government department ofthe city/municipality that the airport in question services) are servicecenters at an airport. Many FBOs provide services such as aircraftfueling, aircraft storage, chartering, baggage handling, rental carservice, and some maintenance.

In one embodiment of the present invention, users of the reservationbooking website who are GA travelers and in need of a rental vehicle canuse utilize the GA/FBO functionality of an embodiment of the presentinvention. With this functionality, the reservation booking websitepreferably automatically sets some aspect of the reservation based atleast in part upon GA travel data provided by the customer. In apreferred embodiment, the website automatically selects a branchlocation for the reservation based upon the customer's identification ofthe FBO that is serving his/her GA flight. This automatic selectionalleviates the need for the customer to guess which branch location ismost convenient to serve as the branch location for the rental.

FIG. 74 is a flowchart depicting this GA/FBO functionality in thecontext of booking a reservation through a GA path within thereservation booking website. The GA reservation creation path preferablycomprises a sequence of pages on the website that are configured tointeract with the customer to create a rental vehicle reservation,wherein at least one of these pages is responsive to the customer'sidentified GA travel plans.

One manner by which the GA/FBO functionality can be accessed bycustomers involves the customer beginning the reservation creationprocess as per, for example, the homepage of FIG. 37. If the customer,during this reservation creation process, provides data input indicativeof an airport location, then at step 74.1, the customer is provided witha selectable link for accessing the GA/FBO functionality. Examples ofthe data input that are preferably operable to result in a GA/FBO linkbeing provided are the input of an airport code into field 302 of thehome page (see FIG. 37), the selection of a “show airports only” link520 from a “Choose Location” page (see FIG. 38( b)), or selection of alink that is operative to pull up a list of all airport codes.

FIGS. 75( a)-(d) illustrate preferable examples of pages that includethe GA/FBO link 7500. The page of FIG. 75( a) is a “choose vehicle” pagereached after the customer has previously entered an airport code infield 302 of the home page (see FIG. 37), but has not yet selected avehicle for the reservation. Link 7500 is preferably presented on this“choose vehicle” page for customer selection if the customer istraveling via GA and desires to book his/her reservation in accordancetherewith. The page of FIG. 75( b) is a “branch details” page reachedafter the customer has previously entered an airport code in field 302and a vehicle class in field 314 of the home page (see FIG. 37). As canbe seen, link 7500 is also presented on this “branch details” page forcustomer selection to access the GA/FBO functionality. The page of FIG.75( c) is a page that presents a choice of airport locations forcustomers. This page, which is reached upon customer selection of link520 depicted in FIG. 38( b), also includes customer-selectable link7500. FIG. 75( d), which is a list of airport codes available forselection by the customer, is preferably reached after the customer hasselected a link from the home page that is operative to show the airportcodes for different airports. This list of airport codes is preferablypresented in a pop-up window and includes only airports having scheduledcommercial airline traffic. However, if desired by a practitioner of thepresent invention, this page can optionally include a list of allairport locations and codes, for both airports serving commercialairlines and for airports serving only GA flights. Link 7500 ispreferably provided on the page of FIG. 75( d) to allow the customer toaccess the GA/FBO functionality.

Upon customer selection of a GA/FBO link 7500 at step 74.3, the customeris taken to the GA/FBO homepage 7600 of FIG. 76 (step 74.4). If thecustomer does not select the GA/FBO link 7500 at step 74.3, then thereservation creation process for the customer continues down the regularnon-GA path (which can be referred to as the commercial aviation path).It is also worth noting that customers can also preferably reach page7600 (step 74.4) directly via a URL corresponding to page 7600. Forexample, in a preferred embodiment, the URL http://www.enterprise.com/GAis operative to bring a customer directly to page 7600.

Page 7600 is highly similar to the home page of FIG. 37 except that page7600 is specific to the GA/FBO functionality. In a preferred embodiment,the user is only allowed to enter an airport code in field 7604 toinitiate the branch location selection process for the reservation. Ifthe customer does not know the airport code for the particular airportof interest, then “airport code” link 7602 is provided for customerselection to call up pop-up window 7700 shown in FIG. 77. However, asshould be understood by those of ordinary skill in the art, other dataentry options for identifying an airport can be used. For example, field7604 can also be implemented to allow the customer to enter the name ofa city or state to help the website narrow down the range of airportsthat may be of interest to the customer. In such cases, the customercould in turn be taken to a “choose airport” page (such as that shown inFIG. 75( c)) or the like.

FIG. 77 depicts a pop-up window that identifies the airport codes forall airports, including GA airports, in the U.S. Table 7702 in FIG. 77includes column 7704 for identifying the pertinent city, column 7706 foridentifying the corresponding airport name, and column 7708 foridentifying the airport code for each airport listed in column 7706.Links 7712 are available for customer selection to make table 7702 listairport codes for other countries, such as Canada, the UK, or Ireland.Link 7710 is provided to return the customer, upon selection thereof, tothe non-GA/FBO reservation path.

Returning to FIG. 76, once the customer has entered an airport code infield 7604 (step 74.5) and selected the “search” button 7606, thecustomer is taken to a “choose FBO” page 7800 (step 74.6). FIG. 78depicts a preferred “choose FBO” page 7800. Page 7800 presents thecustomer with a list 7802 a, 7802 b, . . . of available FBOs forselection at the chosen airport. Each FBO that is listed is accompaniedby a corresponding “select” button 7806. Furthermore, summary section330 is augmented to include an “FBO selected” section 7804 thatidentifies which FBO the customer has selected. If the number of FBOsavailable at the chosen airport are too numerous to conveniently fit ona single page, then it is preferred that a link 7808 be provided toaccess the remaining FBOs available for selection. Further still, link7710 is also provided on page 7800 to allow the customer to return tothe regular non-GA reservation path.

Once the customer has selected the appropriate FBO for his/her travelplans (step 74.7), then the reservation booking website preferablyautomatically selects a branch location for the reservation based on theFBO that the customer has selected (step 74.8). Preferably, thisautomatically selected branch location is the branch location mostconvenient to the chosen FBO. In most instances, this branch locationwill be the branch location closest to the chosen FBO. With reference toFIG. 6, database 206 or database 208 can preferably associate each FBOwith a particular branch location to enable this automatic selectionprocess.

Alternatively, at step 74.8, rather than automatically selecting abranch location for the customer based in the chosen FBO, thereservation booking website can suggest a branch location for thereservation. The suggested branch location would preferably be displayedon a “Choose Location” page together with a message that communicates tothe customer the website's recommendation to use that branch locationgiven the customer's chosen FBO. This suggested branch location wouldpreferably be the branch location that would be automatically selectedin other embodiments of the invention. If the customer then desires tobook the reservation at this suggested branch location, he/she cansubmit data input to the website indicative of that selection.Furthermore, rather than suggest a single branch location for thereservation, the “Choose Location” page can suggest a plurality ofbranch locations. These plurality of suggested branch locations canpreferably be displayed in a ranked order with the first suggestedlocation being the branch location that would be automatically selectedin other embodiments of the invention and the remaining branch locationsbeing the branch locations that are closest to the suggested branchlocation.

After step 74.8, the pages of FIG. 79( a) or 79(b) are preferablypresented to the customer. The page 7900 of FIG. 79( a) would be reachedwhen the customer has selected the FBO for the reservation but has notyet selected the vehicle class. Page 7910 of FIG. 79( b) would bereached when the customer had already selected the vehicle class priorto his/her selection of the FBO. The summary sections 330 for both FIGS.79( a) and (b) identify the chosen FBO in field 7804 together with theautomatically selected branch location in field 346. Link 7902 ispreferably provided to allow the user to change his/her selection of anFBO for the reservation. Link 360 is preferably provided to allow theuser to change the branch location for the reservation. Once again, bothpages 7900 and 7910 preferably include a link 7710 for returning to theregular non-GA reservation path.

Many FBOs have their own corporate accounts or business arrangementswith rental vehicle providers. Through such accounts/arrangements, therental rates for a particular FBO may be different (e.g., lessexpensive) than the standard rental rate offered at the branch locationin question. Practitioners of the present invention may prefer to havethe price for the customer's reservation automatically set equal to theapplicable rates for the chosen FBO as determined by the chosen FBO'scorporate account or other arrangement. In such cases, the prices shownin column 7906 in FIG. 79( a) and at field 7904 in FIG. 79( b) can thusbe automatically selected based on a daily rental rate available to theFBO. Furthermore, if an FBO's rate is higher than another rate availableto the customer, the reservation booking website can also be set up toautomatically select the lower of the available rates. Further still,where the system has a plurality of rates to choose from for a givenreservation, it is preferred that some type of priority ranking schedulebe used to determine the rate chosen for the reservation. This schedulecan be a “lowest rate” rule, or it can be a ranked hierarchy by ratetype (e.g., (1) if the customer has a customer account with anassociated rate, select that rate, (2) if not (1), then if the selectedFBO has a rate associated therewith, select the FBO's associated rate,or (3) if not (1) or (2), if FBOs generically have an associated defaultrate, then select the default rate).

Furthermore, in addition to rates, other aspects of an FBO'saccount/arrangement with a rental vehicle service provider may affect acustomer's reservation within the GA reservation path. For example,parameters such as “unlimited mileage”, “prepaid gas”, and the like cancarry over from an FBO's account/arrangement into a reservation for acustomer who books a reservation through a particular FBO within the GAreservation path.

From the pages of FIGS. 79( a) and (b), the customer can provide furtherreservation data to effectuate completion of the reservation (step74.9). Preferably, once the customer has provided all appropriatereservation data and provided confirmation thereof, the reservationbooking website books the reservation (step 74.10).

In yet another embodiment of the present invention, the inventors hereinhave improved the process through which customers can create a rentalvehicle reservation by providing customers for whom the reservationbooking website stores a customer profile or account with a streamlinedability to log into their profiles/accounts.

With conventional reservation booking websites known to the inventorsherein, customers who have previously created a customer profile withthe reservation booking website will typically have to access a separate“log in” page to log into their profile/account. To reach such aseparate log in page, the customer has to exit a page that is configuredto interact with the customer to obtain reservation data. That is tosay, if the customer is on a page that is asking for the customer tochoose a vehicle class for the reservation and the customer desires tolog in to his/her profile/account, the customer typically must select a“log in” link or the like on that page. Upon selection of the “log in”link, the customer is taken to a new page in which the customer isrequested to enter his/her User Name and/or Password. Once successfullylogging into his/her profile/account, the customer can return to a pagein the reservation creation path to complete the reservation.

In an effort to improve upon this log in process, the inventors hereinhave included fields for logging into customer profiles on a pluralityof pages in the reservation creation path. Preferably, each page that isdisplayed to the customer before the customer has logged into his/herprofile/account includes a log in field. For example, with thisembodiment of the present invention, not only does the home page includefields in which a customer can enter his/her User Name and Password, butpreferably the Choose Location pages, Choose Vehicle pages, BranchDetails pages, Vehicle Details pages, and Renter Information pages alsoinclude log in fields for accessing customer profiles.

In embodiments where the customer profiles include detailed customerinformation such as name, address, and optionally other information, thecustomer can bypass data entry on the Renter Information page (such asthat shown in FIGS. 50 a and b) by successfully logging into his/herprofile via the fields provided on the displayed page. In such cases,the Renter Information page need not be displayed on the customer'scomputer.

In other embodiments where the customer profiles include additionalinformation such as preferred vehicle class and/or preferred branchlocation, the customer can preferably also bypass data entry on theChoose Vehicle and/or Choose Location pages. For example, if acustomer's profile has a stored “favorite” vehicle class, the websiteneed not present the Choose Vehicle page or the Renter Information pageto the customer if the customer has logged into his/her profile prior tothe point in the reservation creation path where the Choose Vehicle pagewould be displayed. If for some reason the customer did not want toreserve a rental vehicle matching his/her preferred vehicle class, theuser is preferably provided with the option to change the selection ofvehicle class via the appropriate edit link in the summary section 330.Similarly, if the customer wanted to change the renter information forthe reservation, he/she can preferably also do so via the appropriateedit link in the summary section 330. Likewise, if the customer profileidentifies a preferred branch location and the customer has logged intothe profile while creating a reservation, the reservation bookingwebsite need not present a Choose Location page to the customer. If thecustomer later does not want to create a reservation at his/her“favorite” branch location, then the customer can change the branchlocation for the reservation using the appropriate edit link in summarysection 330.

FIG. 80( a) depicts a preferred home page for a reservation bookingwebsite wherein a customer profile log in section 8000 is provided. Thiscustomer profile log in section 8000 includes field 8002 in which thecustomer can provide the appropriate password to access his/her customerprofile. Section 8000 is preferably displayed when the customer haspreviously created a customer profile and a “cookie” or the like ispresent on the customer computer that allows the reservation bookingwebsite to recognize the customer computer as being associated with aparticular customer. In the example of FIG. 80( a), the customer “John”has been recognized via a “cookie” on his computer. Link 8006 isprovided for customer selection if the user of the customer computer isnot “John” or does not want to be recognized as “John” for the purposesof the reservation. Upon entry of the appropriate password in field 8002and the selection of the “login” button 8004, “John” will access hiscustomer profile, thereby enabling him to bypass at least the RenterInformation page.

FIG. 80( b) is an exemplary Choose Location page on which the customerprofile log in section 8000 is present. The Choose Location page of FIG.80( b) also includes a summary section 330. As can be seen in field 354of summary section 330, the customer has not yet provided any RenterInformation during the reservation creation process nor has the customeraccessed his profile via section 8000.

FIG. 80( c) is an exemplary Choose Vehicle page on which the customerprofile log in section 8000 is present. As with the example of FIG. 80(b), it can be seen in field 354 of summary section 330 that the customerhas not yet provided any Renter Information during the reservationcreation process nor has the customer accessed his profile via section8000.

Similarly, FIG. 80( d) is an exemplary Renter Information page on whichcustomer profile log in section 8000 is present. FIG. 80( e) is anexemplary Branch Details page on which customer profile log in section8000 is present, and FIG. 80( f) is an exemplary Vehicle Details page onwhich customer profile log in section 8000 is present.

Once the customer has successfully logged into his/her customer profile,then that customer can bypass one or more stages in the reservationcreation process if the data needed for completion of those stages isfound in the customer's profile. For example, if the customer were tosuccessfully log in via section 8000 of FIG. 80( b), then the page ofFIG. 81 is preferably displayed. As can be seen in FIG. 81, the RenterInformation field 354 of summary section 330 has been automaticallypopulated by the Renter Information stored in John's customer profile.As John proceeds through the reservation creation process, the websitewill preferably not display a Renter Information page on his computer.Optionally, if John's customer profile also included a favorite branchlocation and/or a favorite vehicle class, the website can also beconfigured such that John will bypass the Choose Vehicle page and/or theChoose Location page.

In the exemplary screenshots of FIGS. 80( a)-(f) and 81, the customerprofile log in section 8000 included only a field 8000 for thecustomer's password to his/her profile. A field for customer entry ofthe customer's User Name was not needed because the website “recognized”the customer via a “cookie” on the customer's computer. In cases wherethe customer is not recognized via a cookie (or even in cases wherefurther security is desired), the pages can also include a field forcustomer entry of a User Name as shown in FIG. 82. FIG. 82 depicts analternate customer profile log in section 8200 wherein a field 8202 isprovided for the customer's User Name as well as a field 8204 for thecustomer's Password. “Log in” button 8206 is provided for customerselection to log into the appropriate customer profile. In thisembodiment of the invention, section 8000 in FIGS. 80( a)-(f) can bereplaced with section 8200.

Furthermore, it is worth noting that if the customer has alreadyprovided reservation data on the page from which the customer logs intohis/her profile/account, a practitioner of the present invention canoptionally use the provided reservation data for populating fields ofthe reservation. That is to say, if the customer has already specified avehicle class for his/her reservation on the home page, but prior toselecting the “search” button on the home page the customer has insteadlogged into his/her account/profile, the reservation field for vehicletype can be populated with the customer specified vehicle class, therebyrouting the customer to a Choose Location page after logging in.Optionally, the website can also be configured to, upon customer log in,return the customer to the page from which he/she logged into theprofile/account.

While the present invention has been described above in relation to itspreferred embodiment, various modifications may be made thereto thatstill fall within the invention's scope, as would be recognized by thoseof ordinary skill in the art. Such modifications to the invention willbe recognizable upon review of the teachings herein. As such, the fullscope of the present invention is to be defined solely by the appendedclaims and their legal equivalents.

What is claimed is:
 1. A method of facilitating the booking of rentalvehicle reservations through a plurality of user interface screens fordisplay on a user computer to interact with a user of the user computerto create a rental vehicle reservation with a rental vehicle serviceprovider, the method comprising: providing a general aviation (GA)rental vehicle reservation creation path through the user interfacescreens for customers whose rental vehicle needs are based upon plans totravel via GA, the GA rental vehicle reservation creation pathcomprising a subplurality of the user interface screens that areconfigured to request a plurality of types of data input for processingby a server to create a rental vehicle reservation; providing acommercial aviation rental vehicle reservation creation path through theuser interface screens for customers whose rental vehicle needs arebased upon plans to travel via commercial aviation, the commercialaviation rental vehicle reservation creation path comprising asubplurality of the user interface screens that are configured torequest a plurality of types of data input for processing by the serverto create a rental vehicle reservation, wherein the types of data inputand data processing required for the commercial aviation rental vehiclereservation creation path are different than the types of data input anddata processing required by the GA rental vehicle reservation creationpath; and wherein the method steps are performed by the server.
 2. Themethod of claim 1 wherein the server is configured to host a rentalvehicle reservation booking website, the website comprising theplurality of user interface screens.
 3. The method of claim 2 furthercomprising: the server providing a link on a user interface screenwithin the website, the link being selectable by the user to indicatethat the user's rental vehicle need is based at least partially on aplan by the user to travel via GA, wherein user selection of the link iseffective to place the user on the GA rental vehicle reservationcreation path.
 4. The method of claim 2 wherein the GA rental vehiclereservation creation path providing step includes the server providing auser interface screen for display on the user computer, wherein the userinterface screen includes a link selectable by the user to change theuser's path to the commercial aviation rental vehicle reservationcreation path.
 5. The method of claim 1 wherein the step of providingthe GA rental vehicle reservation creation path comprises the serverproviding at least one user interface screen configured to request anidentification from the user of a fixed based operator (FBO)corresponding to the user's plan to travel via GA.
 6. The method ofclaim 1 wherein the step of providing the GA rental vehicle reservationcreation path comprises the server providing at least one user interfacescreen configured to list a plurality of GA airports for selection bythe user, and wherein the step of providing the commercial aviationrental vehicle reservation creation path comprises the server providingat least one user interface screen configured to list a plurality ofcommercial aviation airports for selection by the user.
 7. An apparatusfor facilitating the booking of rental vehicle reservations with arental vehicle service provider, the apparatus comprising: a serveraccessible over a network to a user computer, the server beingconfigured to provide a user computer with access to a plurality of userinterface screens via a plurality of paths for the user computer tocreate a rental vehicle reservation in response to input from the usercomputer, the plurality of paths including a first path and a secondpath; the first path being configured for customers whose rental vehicleneeds are based upon plans to travel via general aviation (GA), thefirst path comprising a subplurality of the user interface screens thatare configured to request a plurality of types of data input forprocessing by the server to create a rental vehicle reservation; thesecond path being configured for customers whose rental vehicle needsare not based upon plans to travel via GA, the second path comprising asubplurality of user interface screens that are configured to request aplurality of types of data input for processing by the server to createa rental vehicle reservation; and wherein the types of data input anddata processing required for the first path are different than the typesof data input and data processing required by the second path.
 8. Theapparatus of claim 7 wherein the server is configured to host a websitethat comprises the plurality of user interface screens.
 9. The apparatusof claim 8 wherein the server is further configured to provide a link ona user interface screen within the website, the link being selectable bya user of the user computer to indicate that the user's rental vehicleneed is based at least partially on a plan by the user to travel via GA,wherein user selection of the link is effective to place the user on thefirst path.
 10. The apparatus of claim 8 wherein at least one of theuser interface screens of the first path includes a link selectable bythe user to change the user's path to the second path.
 11. The apparatusof claim 7 wherein at least one of the user interface screens of thefirst path is configured to request an identification from the user of afixed based operator (FBO) corresponding to the user's plan to travelvia GA.
 12. The apparatus of claim 7 wherein at least one of the userinterface screens of the first path is configured to list a plurality ofGA airports for selection by the user, and wherein at least one of theuser interface screens of the second path is configured to list aplurality of commercial aviation airports for selection by the user.